Age | Commit message (Collapse) | Author |
|
a variable. The previous code would break the debug info changing
code invariant. This will regress debug info for arguments where
we elide the alloca created.
Fixes rdar://11066468
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153074 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153073 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153072 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153071 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1) opt is not usually in the same path as the target program. Even for
the bugpoint as a standalone app, it should be more portable to search
in PATH, isn't it?
2) bugpoint driver accounts opt plugins, but does not list them in the
final output command.
Patch by Dmitry Mikushin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
errors).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153065 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153064 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://11059157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153055 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://11057160
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153051 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also add some documentation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Weiming Zhao!
This fixes PR12212
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions have been scheduled. Handy for tracking down scheduler bugs, or
bugs exposed by scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153045 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
they are currently used only for experiments
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153038 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153035 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
X86InstrCompiler.td.
It also adds –mcpu-generic to the legalize-shift-64.ll test so the test
will pass if run on an Intel Atom CPU, which would otherwise
produce an instruction schedule which differs from that which the test expects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153033 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
violations I introduced. Also sort some of the instructions to get
a more consistent ordering.
Suggestions on still better / more consistent formatting would be
welcome. I'm actually tempted to use a macro to define all of the
delegate methods...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153030 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type hierarchy. I wanted to use this for the inline cost rewrite, and
found it was missing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153029 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
overflow checking multiply intrinsic as well.
Add a test for this, updating the test from grep to FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153027 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks to Eli for noticing the discrepancy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153011 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
some superfluous forward declarations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is particularly helpful as both arguments tend to be constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152991 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152981 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152980 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
other targets and the base class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
evaluated to '1' when the argument list was empty (should be '0').
rdar://11057257
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152967 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fast-isel before emitting code. If the program bails after code was emitted,
then it could lead to the stack being adjusted more than once (two
CALLSEQ_BEGINs emitted) but being adjuste back only once after the call. This
leads to general badness and gnashing of teeth.
<rdar://problem/11050630>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://11065671
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152954 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152946 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.
rdar://11064740
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152943 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152935 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the beginning, no need to maintain another set for the added regs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152934 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
number in padding.
Saves one machine word on MachineInstr (88->80 bytes on x86_64, 48->44 on i386).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152930 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the cached value.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152927 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(obsoleted) written_files[].
In previous case,
RUN: foo -o %t
RUN: FileCheck < %t
RUN: bar -o %t
2nd read handle might prevent manipulation of 3rd %t in bar, to remove and rename.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152916 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We can simply confirm the handle released to open it with EXCLUSIVE. Attempting renaming was bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
alignment. If that's the case, then we want to make sure that we don't increase
the alignment of the store instruction. Because if we increase it to be "more
aligned" than the pointer, code-gen may use instructions which require a greater
alignment than the pointer guarantees.
<rdar://problem/11043589>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It was added in 2007 as the first cut at supporting no-inline
attributes, but we didn't have function attributes of any form at the
time. However, it was added without any mention in the LangRef or other
documentation.
Later on, in 2008, Devang added function notes for 'inline=never' and
then turned them into proper function attributes. From that point
onward, as far as I can tell, the world moved on, and no one has touched
'llvm.noinline' in any meaningful way since.
It's time has now come. We have had better mechanisms for doing this for
a long time, all the frontends I'm aware of use them, and this is just
holding back progress. Given that it was never a documented feature of
the IR, I've provided no auto-upgrade support. If people know of real,
in-the-wild bitcode that relies on this, yell at me and I'll add it, but
I *seriously* doubt anyone cares.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
directly query the function information which this set was representing.
This simplifies the interface of the inline cost analysis, and makes the
always-inline pass significantly more efficient.
Previously, always-inline would first make a single set of every
function in the module *except* those marked with the always-inline
attribute. It would then query this set at every call site to see if the
function was a member of the set, and if so, refuse to inline it. This
is quite wasteful. Instead, simply check the function attribute directly
when looking at the callsite.
The normal inliner also had similar redundancy. It added every function
in the module with the noinline attribute to its set to ignore, even
though inside the cost analysis function we *already tested* the
noinline attribute and produced the same result.
The only tricky part of removing this is that we have to be able to
correctly remove only the functions inlined by the always-inline pass
when finalizing, which requires a bit of a hack. Still, much less of
a hack than the set of all non-always-inline functions was. While I was
touching this function, I switched a heavy-weight set to a vector with
sort+unique. The algorithm already had a two-phase insert and removal
pattern, we were just needlessly paying the uniquing cost on every
insert.
This probably speeds up some compiles by a small amount (-O0 compiles
with lots of always-inline, so potentially heavy libc++ users), but I've
not tried to measure it.
I believe there is no functional change here, but yell if you spot one.
None are intended.
Finally, the direction this is going in is to greatly simplify the
inline cost query interface so that we can replace its implementation
with a much more clever one. Along the way, all the APIs get simplified,
so it seems incrementally good.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152903 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reference instead of value to avoid some copying.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
analysis implementation. The header was already separated. Also cleanup
all the comments in the header to follow a nice modern doxygen form.
There is still plenty of cruft here, but some of that will fall out in
subsequent refactorings and this was an easy step in the right
direction. No functionality changed here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152898 91177308-0d34-0410-b5e6-96231b3b80d8
|