| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
legalizetypes.
llvm-svn: 58714
|
| |
|
|
| |
llvm-svn: 58709
|
| |
|
|
| |
llvm-svn: 58708
|
| |
|
|
| |
llvm-svn: 58707
|
| |
|
|
|
|
| |
SELECT_CC.
llvm-svn: 58706
|
| |
|
|
|
|
| |
be considerably simplified.
llvm-svn: 58703
|
| |
|
|
| |
llvm-svn: 58702
|
| |
|
|
| |
llvm-svn: 58701
|
| |
|
|
| |
llvm-svn: 58697
|
| |
|
|
| |
llvm-svn: 58696
|
| |
|
|
| |
llvm-svn: 58694
|
| |
|
|
| |
llvm-svn: 58693
|
| |
|
|
| |
llvm-svn: 58690
|
| |
|
|
|
|
|
|
| |
as the MachineCodeEmitter allocated memory. Code and data has different read / write / execution privilege requirements.
This is a short term workaround. The current solution is for the JIT memory manager to manage code and data memory separately.
llvm-svn: 58688
|
| |
|
|
| |
llvm-svn: 58684
|
| |
|
|
| |
llvm-svn: 58683
|
| |
|
|
| |
llvm-svn: 58682
|
| |
|
|
| |
llvm-svn: 58676
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The prologue is modified to read the __stack_chk_guard global and insert it
onto the stack.
* The epilogue is modified to read the stored guard from the stack and compare
it to the original __stack_chk_guard value. If they differ, then the
__stack_chk_fail() function is called.
* The stack protector needs to be first on the stack (after the parameters) to
catch any stack-smashing activities.
Front-end support will follow after a round of beta testing.
llvm-svn: 58673
|
| |
|
|
| |
llvm-svn: 58671
|
| |
|
|
|
|
|
| |
have its node id set. The new and and shift nodes are the nodes that need
the IDs. This fixes PR2982.
llvm-svn: 58655
|
| |
|
|
| |
llvm-svn: 58653
|
| |
|
|
| |
llvm-svn: 58651
|
| |
|
|
| |
llvm-svn: 58650
|
| |
|
|
| |
llvm-svn: 58644
|
| |
|
|
| |
llvm-svn: 58643
|
| |
|
|
|
|
|
| |
work correctly, and bring over a late change to ppcf128
SetCC handling.
llvm-svn: 58642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sized integers like i129, and also reduce the number
of assumptions made about how vaarg is implemented.
This still doesn't work correctly for small integers
like (eg) i1 on x86, since x86 passes each of them
(essentially an i8) in a 4 byte stack slot, so the
pointer needs to be advanced by 4 bytes not by 1 byte
as now. But this is no longer a LegalizeTypes problem
(it was also wrong in LT before): it is a bug in the
operation expansion in LegalizeDAG: now LegalizeTypes
turns an i1 vaarg into an i8 vaarg which would work
fine if only the i8 vaarg was turned into correct code
later.
llvm-svn: 58635
|
| |
|
|
|
|
|
| |
to avoid overload ambiguities. This fixes build errors introduced
by r58623.
llvm-svn: 58632
|
| |
|
|
| |
llvm-svn: 58631
|
| |
|
|
|
|
| |
would be hard pressed to be considered a sentence, but if it makes Bill happy...
llvm-svn: 58630
|
| |
|
|
|
|
| |
fill in, but the basics are there.
llvm-svn: 58626
|
| |
|
|
|
|
|
|
| |
This allows SCEV users to effectively calculate trip count.
LSR later on transforms back integer IVs to floating point IVs
later on to avoid int-to-float casts inside the loop.
llvm-svn: 58625
|
| |
|
|
|
|
| |
adding a TargetMachine member to the base TargetAsmInfo class instead.
llvm-svn: 58624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bits, use a union of a SimpleValueType enum and a regular Type*.
This increases the size of MVT on 64-bit hosts from 32 bits to 64 bits.
In most cases, this doesn't add significant overhead. There are places
in codegen that use arrays of MVTs, so these are now larger, but
they're small in common cases.
This eliminates restrictions on the size of integer types and vector
types that can be represented in codegen. As the included testcase
demonstrates, it's now possible to codegen very large add operations.
There are still some complications with using very large types. PR2880
is still open so they can't be used as return values on normal targets,
there are no libcalls defined for very large integers so operations
like multiply and divide aren't supported.
This also introduces a minimal tablgen Type library, capable of
handling IntegerType and VectorType. This will allow parts of
TableGen that don't depend on using SimpleValueType values to handle
arbitrary integer and vector types.
llvm-svn: 58623
|
| |
|
|
|
|
| |
specializing
llvm-svn: 58615
|
| |
|
|
|
|
| |
10 bytes long, but is passed in 12/16 bytes).
llvm-svn: 58608
|
| |
|
|
| |
llvm-svn: 58606
|
| |
|
|
| |
llvm-svn: 58598
|
| |
|
|
| |
llvm-svn: 58593
|
| |
|
|
|
|
| |
We're still waiting on code that actually analyzes them properly.
llvm-svn: 58592
|
| |
|
|
| |
llvm-svn: 58591
|
| |
|
|
|
|
|
|
| |
* merge two weak functions by making them both alias a third non-weak fn
* don't reimplement CallSite::hasArgument
* whitelist the safe linkage types
llvm-svn: 58568
|
| |
|
|
| |
llvm-svn: 58563
|
| |
|
|
|
|
|
| |
cast from ‘const llvm::PointerType*’ to ‘unsigned int’
loses precision).
llvm-svn: 58561
|
| |
|
|
|
|
|
|
|
| |
exist before. Updating the live intervals in that care is tricky in the general
case.
Evan, if you see a tighter guard condition for this, let me know.
llvm-svn: 58560
|
| |
|
|
| |
llvm-svn: 58559
|
| |
|
|
|
|
|
|
| |
This triggers only 60 times in llvm-test (look at .llvm.bc, not .linked.rbc)
and so it probably wont be turned on by default. Also, may of those are likely
to go away when PR2973 is fixed.
llvm-svn: 58557
|
| |
|
|
|
|
| |
by Richard Osborne.
llvm-svn: 58555
|
| |
|
|
|
|
|
| |
ConstantInt, and SI is the original cast instruction. This fixes
PR2996.
llvm-svn: 58549
|