| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 61947
|
| |
|
|
|
|
|
|
|
|
|
| |
functions that don't already have a (dynamic) alloca.
Dynamic allocas cause inefficient codegen and we shouldn't
propagate this (behavior follows gcc). Two existing tests
assumed such inlining would be done; they are hacked by
adding an alloca in the caller, preserving the point of
the tests.
llvm-svn: 61946
|
| |
|
|
|
|
| |
day when more linkage types will be handled.
llvm-svn: 61944
|
| |
|
|
|
|
|
|
| |
will get its preferred alignment. It has to be careful and cautiously assume
it will just get the ABI alignment. This prevents instcombine from rounding
up the alignment of a load/store without adjusting the alignment of the alloca.
llvm-svn: 61934
|
| |
|
|
|
|
|
| |
llvm-as: t.ll:2:39: function may not return opaque type
%"bwmoyl" = tail call coldcc opaque @g()
^
llvm-svn: 61933
|
| |
|
|
| |
llvm-svn: 61932
|
| |
|
|
|
|
| |
keeping.
llvm-svn: 61931
|
| |
|
|
| |
llvm-svn: 61928
|
| |
|
|
|
|
| |
* Removed trailing whitespace
llvm-svn: 61927
|
| |
|
|
|
|
| |
* Removed trailing whitespace
llvm-svn: 61926
|
| |
|
|
|
|
| |
specialization apply only to the tests that are actually testing it.
llvm-svn: 61923
|
| |
|
|
|
|
|
|
|
| |
StringMapEntryInitializer classes. Leave it for the compiler to figure out what
the type is and what "0" should be transformed into.
* Un-disable the unit tests which test the StringMapEntryInitializer class.
llvm-svn: 61922
|
| |
|
|
|
|
|
|
| |
check242, which invalidates this test. This test is an x86-32 ABI test
that is trying to be run in a target-independent way, which is not going
to work very well. Just remove the test.
llvm-svn: 61921
|
| |
|
|
| |
llvm-svn: 61919
|
| |
|
|
| |
llvm-svn: 61918
|
| |
|
|
| |
llvm-svn: 61917
|
| |
|
|
| |
llvm-svn: 61916
|
| |
|
|
|
|
|
|
|
| |
loads from allocas that cover the entire aggregate. This handles
some memcpy/byval cases that are produced by llvm-gcc. This triggers
a few times in kc++ (with std::pair<std::_Rb_tree_const_iterator
<kc::impl_abstract_phylum*>,bool>) and once in 176.gcc (with %struct..0anon).
llvm-svn: 61915
|
| |
|
|
|
|
|
|
|
| |
* Fixed but in StringMap::clear()
* Removed trailing whitespace
Original patch by Talin.
llvm-svn: 61914
|
| |
|
|
|
|
| |
Again, shamelessly copied from MMI.
llvm-svn: 61912
|
| |
|
|
|
|
| |
This is a shameless copy of similar APIs from MachineModuleInfo. The copy from MMI will be deleted in near future.
llvm-svn: 61908
|
| |
|
|
|
|
| |
* Removed trailing whitespace
llvm-svn: 61907
|
| |
|
|
| |
llvm-svn: 61906
|
| |
|
|
|
|
| |
whitespace.
llvm-svn: 61905
|
| |
|
|
| |
llvm-svn: 61904
|
| |
|
|
|
|
|
|
|
|
|
| |
passed in to this function changed to support multiple return values,
leading to some incorrect argument numbers in the failure messages.
With this change, the ArgNo values used for return values and parameters are
disjoint, and the new IntrinsicParam function translates those ArgNo values
to strings that can be used in the messages. This also fixes a few places
where PerformTypeCheck did not return false following calls to CheckFailed.
llvm-svn: 61903
|
| |
|
|
| |
llvm-svn: 61900
|
| |
|
|
|
|
| |
odd bit-width vector elements. Add a check in the verifier for this also.
llvm-svn: 61899
|
| |
|
|
| |
llvm-svn: 61898
|
| |
|
|
|
|
| |
The error was reported by gcc-4.3.0 during compilation.
llvm-svn: 61896
|
| |
|
|
| |
llvm-svn: 61895
|
| |
|
|
| |
llvm-svn: 61893
|
| |
|
|
| |
llvm-svn: 61891
|
| |
|
|
| |
llvm-svn: 61890
|
| |
|
|
|
|
|
|
|
| |
* Fixed {copy,assignment} constructor test names
* s/EXPECT_EQ(true, ...)/ASSERT_TRUE(...)/
Patch by Talin.
llvm-svn: 61883
|
| |
|
|
| |
llvm-svn: 61879
|
| |
|
|
|
|
|
|
|
|
| |
was it not very helpful, it was also wrong! The problem
is shown in the testcase: the alloca might be passed to
a nocapture callee which dereferences it and returns the
original pointer. But because it was a nocapture call we
think we don't need to track its uses, but we do.
llvm-svn: 61876
|
| |
|
|
|
|
| |
Based on a bug report by Yonggang Luo.
llvm-svn: 61875
|
| |
|
|
| |
llvm-svn: 61873
|
| |
|
|
| |
llvm-svn: 61872
|
| |
|
|
| |
llvm-svn: 61870
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer to a (transitive) bitcast the alloca and if that integer
has the full size of the alloca, then it clobbers the whole thing.
Handle this by extracting pieces out of the stored integer and
filing them away in the SROA'd elements.
This triggers fairly frequently because the CFE uses integers to
pass small structs by value and the inliner exposes these. For
example, in kimwitu++, I see a bunch of these with i64 stores to
"%struct.std::pair<std::_Rb_tree_const_iterator<kc::impl_abstract_phylum*>,bool>"
In 176.gcc I see a few i32 stores to "%struct..0anon".
In the testcase, this is a difference between compiling test1 to:
_test1:
subl $12, %esp
movl 20(%esp), %eax
movl %eax, 4(%esp)
movl 16(%esp), %eax
movl %eax, (%esp)
movl (%esp), %eax
addl 4(%esp), %eax
addl $12, %esp
ret
vs:
_test1:
movl 8(%esp), %eax
addl 4(%esp), %eax
ret
The second half of this will be to handle loads of the same form.
llvm-svn: 61853
|
| |
|
|
| |
llvm-svn: 61852
|
| |
|
|
|
|
| |
change.
llvm-svn: 61851
|
| |
|
|
|
|
| |
requerying it all over the place.
llvm-svn: 61850
|
| |
|
|
|
|
| |
code, no functionality change.
llvm-svn: 61849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
any of the physical register's sub-register live intervals overlaps with the virtual register. This is overly conservative. It prevents a extract_subreg from being coalesced away:
v1024 = EDI // not killed
=
= EDI
One possible solution is for the coalescer to examine the sub-register live intervals in the same manner as the physical register. Another possibility is to examine defs and uses (when needed) of sub-registers. Both solutions are too expensive. For now, look for "short virtual intervals" and scan instructions to look for conflict instead.
This is a small win on x86-64. e.g. It shaves 403.gcc by ~80 instructions.
llvm-svn: 61847
|
| |
|
|
| |
llvm-svn: 61845
|
| |
|
|
|
|
|
| |
into their left operand, rather than their right. Do this
by commuting the operands and inverting the condition.
llvm-svn: 61842
|
| |
|
|
| |
llvm-svn: 61841
|