terms of store and load, which means bitcasting between scalar
integer and vector has endian-specific results, which undermines
this whole approach.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97137 91177308-0d34-0410-b5e6-96231b3b80d8
keep track of instructions that return void) per-function. This fixes PR5278.
This breaks backwards compatibility with the metadata format. That's okay
because we haven't released the metadata bitcode yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97132 91177308-0d34-0410-b5e6-96231b3b80d8
which branch on undef to branch on a boolean constant for the edge
exiting the loop. This helps ScalarEvolution compute trip counts for
loops.
Teach ScalarEvolution to recognize single-value PHIs, when safe, and
ForgetSymbolicName to forget such single-value PHI nodes as apprpriate
in ForgetSymbolicName.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97126 91177308-0d34-0410-b5e6-96231b3b80d8
format is not parsable, even if the module is legal. To get parsable output,
dump the module instead of the function or smaller, since metadata kind are
attached to the module (not the context).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97124 91177308-0d34-0410-b5e6-96231b3b80d8
(511*16) bytes register displacement (D-form).
NOTE: This is a potential headache, given the SPU's local core limitations,
allowing the software developer to commit stack overrun suicide unknowingly.
Also, large SPU stack frames will cause code size explosion. But, one presumes
that the software developer knows what they're doing...
Contributed by Kalle.Raiskila@nokia.com, edited slightly before commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97091 91177308-0d34-0410-b5e6-96231b3b80d8
GCC_except_table label but before the Lexception, which the FDE references.
This causes problems as the FDE does not point to the start of an LSDA chunk.
Use an unnormalized uleb128 for the call-site table length that includes the
padding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97078 91177308-0d34-0410-b5e6-96231b3b80d8
- Function uses all scratch registers AND
- Function does not use any callee saved registers AND
- Stack size is too big to address with immediate offsets.
In this case a register must be scavenged to calculate the address of a stack
object, and the scavenger needs a spare register or emergency spill slot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97071 91177308-0d34-0410-b5e6-96231b3b80d8
greater-than-or-equal SELECT_CCs to NEON vmin/vmax instructions. This is
only allowed when UnsafeFPMath is set or when at least one of the operands
is known to be nonzero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97065 91177308-0d34-0410-b5e6-96231b3b80d8
the number of value bits, not the number of bits of allocation for in-memory
storage.
Make getTypeStoreSize and getTypeAllocSize work consistently for arrays and
vectors.
Fix several places in CodeGen which compute offsets into in-memory vectors
to use TargetData information.
This fixes PR1784.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97064 91177308-0d34-0410-b5e6-96231b3b80d8
Adding the function "lookupGCCName" to the MBlazeIntrinsicInfo
class to support the Clang MicroBlaze target.
Additionally, minor fixes which remove some unused PIC code
(PIC is not supported yet in the MicroBlaze backend) and
removed some unused variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97054 91177308-0d34-0410-b5e6-96231b3b80d8
necessary to swap the operands to handle NaN and negative zero properly.
Also, reintroduce logic for checking for NaN conditions when forming
SSE min and max instructions, fixed to take into consideration NaNs and
negative zeros. This allows forming min and max instructions in more
cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97025 91177308-0d34-0410-b5e6-96231b3b80d8
to adding them in a determinstic order (bottom up from
the root) based on the structure of the graph itself.
This updates tests for some random changes, interesting
bits: CodeGen/Blackfin/promote-logic.ll no longer crashes.
I have no idea why, but that's good right?
CodeGen/X86/2009-07-16-LoadFoldingBug.ll also fails, but
now compiles to have one fewer constant pool entry, making
the expected load that was being folded disappear. Since it
is an unreduced mass of gnast, I just removed it.
This fixes PR6370
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97023 91177308-0d34-0410-b5e6-96231b3b80d8
memory from three or four registers and VST2 (multiple two-element structures)
which stores to memory from two double-spaced registers.
A8.6.391 & A8.6.393
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97018 91177308-0d34-0410-b5e6-96231b3b80d8
argument is non-null, pass it along to PHITranslateSubExpr so that it can
prefer using existing values that dominate the PredBB, instead of just
blindly picking the first equivalent value that it finds on a uselist.
Also when the DominatorTree is specified, have PHITranslateValue filter
out any result that does not dominate the PredBB. This is basically just
refactoring the check that used to be in GetAvailablePHITranslatedSubExpr
and also in GVN.
Despite my initial expectations, this change does not affect the results
of GVN for any testcases that I could find, but it should help compile time.
Before this change, if PHITranslateSubExpr picked a value that does not
dominate, PHITranslateWithInsertion would then insert a new value, which GVN
would later determine to be redundant and would replace. By picking a good
value to begin with, we save GVN the extra work of inserting and then
replacing a new value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97010 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, LiveIntervalAnalysis would infer phi joins by looking for multiply
defined registers. That doesn't work if the phi join is implicitly defined in
all but one of the predecessors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96994 91177308-0d34-0410-b5e6-96231b3b80d8
With the compiler changed to use EmitCodeAlignment() it does change the
functionality. But X86 assembly code assembled with llvm-mc does not change
its output. For that we will eventually change the assembler frontend to
detect a '.align x, 0x90' when used in a section that 'hasInstructions' and use
EmitCodeAlignment, but will wait until we have better target hooks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96988 91177308-0d34-0410-b5e6-96231b3b80d8
