| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
to fadd, fsub, and fmul, when used with a floating-point type. LLVM
has supported the new instructions since 2.6, so it's time to get
on board.
llvm-svn: 102971
|
|
|
|
| |
llvm-svn: 102959
|
|
|
|
|
|
|
| |
level metadata does not have any function local operands.
This would have caught the problem found in PR6112.
llvm-svn: 102620
|
|
|
|
|
|
|
| |
metadata references in non-function-local MDNodes should drop to
null.
llvm-svn: 102519
|
|
|
|
|
|
|
|
| |
shifts and null vectors. Autoupgrade these to what we'd lower them to.
Add a testcase to exercise this.
llvm-svn: 101851
|
|
|
|
| |
llvm-svn: 101779
|
|
|
|
|
|
|
| |
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
llvm-svn: 101579
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix for self-hosting
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101465
|
|
|
|
| |
llvm-svn: 101438
|
|
|
|
| |
llvm-svn: 101434
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101397
|
|
|
|
| |
llvm-svn: 101376
|
|
|
|
| |
llvm-svn: 101375
|
|
|
|
| |
llvm-svn: 101368
|
|
|
|
|
|
|
|
|
|
| |
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101364
|
|
|
|
|
|
| |
be used in ImmutableCallSite too.
llvm-svn: 101292
|
|
|
|
|
|
| |
incompatibility with some clients covered by the buildbots, such as llvm-gcc.
llvm-svn: 101237
|
|
|
|
| |
llvm-svn: 101233
|
|
|
|
| |
llvm-svn: 101229
|
|
|
|
|
|
|
| |
Type::getInt{1,8,...}[Ptr]Ty, so code can consistently use the methods on Type
without occasionally needed to call IntegerType::get.
llvm-svn: 101111
|
|
|
|
| |
llvm-svn: 101074
|
|
|
|
|
|
| |
patch by Patrick Walton!
llvm-svn: 100932
|
|
|
|
| |
llvm-svn: 100908
|
|
|
|
| |
llvm-svn: 100787
|
|
|
|
| |
llvm-svn: 100774
|
|
|
|
|
|
| |
readability.
llvm-svn: 100756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and use it in one place in inline asm handling stuff. Before
we'd generate this for an invalid modifier letter:
$ clang asm.c -c -o t.o
fatal error: error in backend: Invalid operand found in inline asm: 'abc incl ${0:Z}'
INLINEASM <es:abc incl ${0:Z}>, 10, %EAX<def>, 2147483657, %EAX, 14, %EFLAGS<earlyclobber,def,dead>, <!-1>
Now we generate this:
$ clang asm.c -c -o t.o
error: invalid operand in inline asm: 'incl ${0:Z}'
asm.c:3:12: note: generated from here
__asm__ ("incl %Z0" : "+r" (X));
^
1 error generated.
This is much better but still admittedly not great ("why" is the operand
invalid??), codegen should try harder with its diagnostics :)
llvm-svn: 100723
|
|
|
|
| |
llvm-svn: 100720
|
|
|
|
| |
llvm-svn: 100709
|
|
|
|
| |
llvm-svn: 100702
|
|
|
|
|
|
|
| |
use case where someone wants to resurrect LLVM after calling llvm_shutdown,
but I'm not aware of any clients that are affected by this.
llvm-svn: 100519
|
|
|
|
| |
llvm-svn: 100506
|
|
|
|
|
|
|
| |
Added support for address spaces and added a isVolatile field to memcpy, memmove, and memset,
e.g., llvm.memcpy.i32(i8*, i8*, i32, i32) -> llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)
llvm-svn: 100304
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source addition. Apparently the buildbots were wrong about failures.
---
Add some switches helpful for debugging:
-print-before=<Pass Name>
Dump IR before running pass <Pass Name>.
-print-before-all
Dump IR before running each pass.
-print-after-all
Dump IR after running each pass.
These are helpful when tracking down a miscompilation. It is easy to
get IR dumps and do diffs on them, etc.
To make this work well, add a new getPrinterPass API to Pass so that
each kind of pass (ModulePass, FunctionPass, etc.) can create a Pass
suitable for dumping out the kind of object the Pass works on.
llvm-svn: 100249
|
|
|
|
|
|
| |
beginning of a block.
llvm-svn: 100230
|
|
|
|
|
|
|
| |
This keeps around temporary typedef for clang/llvm-gcc so the
build won't break when I commit this :)
llvm-svn: 100218
|
|
|
|
|
|
| |
are run during codegen.
llvm-svn: 100207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<string> include. For some reason the buildbot choked on this while my
builds did not. It's probably due to a difference in system headers.
---
Add some switches helpful for debugging:
-print-before=<Pass Name>
Dump IR before running pass <Pass Name>.
-print-before-all
Dump IR before running each pass.
-print-after-all
Dump IR after running each pass.
These are helpful when tracking down a miscompilation. It is easy to
get IR dumps and do diffs on them, etc.
To make this work well, add a new getPrinterPass API to Pass so that
each kind of pass (ModulePass, FunctionPass, etc.) can create a Pass
suitable for dumping out the kind of object the Pass works on.
llvm-svn: 100204
|
|
|
|
| |
llvm-svn: 100199
|
|
|
|
|
|
|
| |
Added support for address spaces and added a isVolatile field to memcpy, memmove, and memset,
e.g., llvm.memcpy.i32(i8*, i8*, i32, i32) -> llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)
llvm-svn: 100191
|
|
|
|
| |
llvm-svn: 100146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-print-before=<Pass Name>
Dump IR before running pass <Pass Name>.
-print-before-all
Dump IR before running each pass.
-print-after-all
Dump IR after running each pass.
These are helpful when tracking down a miscompilation. It is easy to
get IR dumps and do diffs on them, etc.
To make this work well, add a new getPrinterPass API to Pass so that
each kind of pass (ModulePass, FunctionPass, etc.) can create a Pass
suitable for dumping out the kind of object the Pass works on.
llvm-svn: 100143
|
|
|
|
|
|
|
|
|
| |
is necessary. Inherits from new templated baseclass CallSiteBase<>
which is highly customizable. Base CallSite on it too, in a configuration
that allows full mutation.
Adapt some call sites in analyses to employ ImmutableCallSite.
llvm-svn: 100100
|
|
|
|
|
|
|
|
|
|
| |
of raw mdnodes. This allows frontends to specify debug
locations without ever creating an MDNode for the DILocation.
This requires a corresponding clang/llvm-gcc change which
I'll try to commit as simultaneously as possible.
llvm-svn: 100095
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being a TrackingVH<MDNode> to a NewDebugLoc, shrinking
sizeof(Instruction) a lot, and providing clients the ability
to deal with locations in terms of NewDebugLoc instead of
having to deal with Metadata. This is still fully compatible
with all clients that *do* use MDNodes for everything of
course.
No functionality change.
llvm-svn: 100088
|
|
|
|
|
|
|
| |
entry in the Scope+InlinedAt drops to a non-canonical form,
we need to reset the idx member of both VH's to 0.
llvm-svn: 100084
|
|
|
|
| |
llvm-svn: 100081
|
|
|
|
| |
llvm-svn: 100074
|
|
|
|
|
|
|
|
|
|
|
|
| |
and will replace the 'DbgInfo' member in Instruction.
The benefit of NewDebugLoc is that it is compact (8 bytes vs 12/24
bytes for the DbgInfo member in Instruction on a 32/64 bit system),
it means that we will end up not having to allocate MDNodes to
represent the "DILocations" in common cases of -O0 -g, and it is
much more efficient to get things out of than the MDNode.
llvm-svn: 100072
|
|
|
|
| |
llvm-svn: 100010
|