captured. This allows the tracker to look at the specific use, which may be
especially interesting for function calls.
Use this to fix 'nocapture' deduction in FunctionAttrs. The existing one does
not iterate until a fixpoint and does not guarantee that it produces the same
result regardless of iteration order. The new implementation builds up a graph
of how arguments are passed from function to function, and uses a bottom-up walk
on the argument-SCCs to assign nocapture. This gets us nocapture more often, and
does so rather efficiently and independent of iteration order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147327 91177308-0d34-0410-b5e6-96231b3b80d8
Promotion of the mask operand needs to be done using PromoteTargetBoolean, and not padded with garbage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147309 91177308-0d34-0410-b5e6-96231b3b80d8
Matching MOVLP mask for AVX (265-bit vectors) was wrong.
The failure was detected by conformance tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147308 91177308-0d34-0410-b5e6-96231b3b80d8
- -25% memory usage of the main table on x86_64 (was wasted in struct padding).
- no significant performance change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147294 91177308-0d34-0410-b5e6-96231b3b80d8
there is non of that type to remove. This fixes a crasher in the particular
case where the instruction has metadata but no metadata storage in the context
(this is only possible if the instruction has !dbg but no other metadata info).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147285 91177308-0d34-0410-b5e6-96231b3b80d8
This was intended to undo the sub canonicalization in cases where it's not profitable, but it also
finds some cases on it's own.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147256 91177308-0d34-0410-b5e6-96231b3b80d8
unsigned foo(unsigned x) { return 31 - __builtin_clz(x); }
now compiles into a single "bsrl" instruction on x86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147255 91177308-0d34-0410-b5e6-96231b3b80d8
This has the obvious advantage of being commutable and is always a win on x86 because
const - x wastes a register there. On less weird architectures this may lead to
a regression because other arithmetic doesn't fuse with it anymore. I'll address that
problem in a followup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147254 91177308-0d34-0410-b5e6-96231b3b80d8
LZCNT instructions are available. Force promotion to i32 to get
a smaller encoding since the fix-ups necessary are just as complex for
either promoted type
We can't do standard promotion for CTLZ when lowering through BSR
because it results in poor code surrounding the 'xor' at the end of this
instruction. Essentially, if we promote the entire CTLZ node to i32, we
end up doing the xor on a 32-bit CTLZ implementation, and then
subtracting appropriately to get back to an i8 value. Instead, our
custom logic just uses the knowledge of the incoming size to compute
a perfect xor. I'd love to know of a way to fix this, but so far I'm
drawing a blank. I suspect the legalizer could be more clever and/or it
could collude with the DAG combiner, but how... ;]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147251 91177308-0d34-0410-b5e6-96231b3b80d8
'bsf' instructions here.
This one is actually debatable to my eyes. It's not clear that any chip
implementing 'tzcnt' would have a slow 'bsf' for any reason, and unless
EFLAGS or a zero input matters, 'tzcnt' is just a longer encoding.
Still, this restores the old behavior with 'tzcnt' enabled for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147246 91177308-0d34-0410-b5e6-96231b3b80d8
X86ISelLowering C++ code. Because this is lowered via an xor wrapped
around a bsr, we want the dagcombine which runs after isel lowering to
have a chance to clean things up. In particular, it is very common to
see code which looks like:
(sizeof(x)*8 - 1) ^ __builtin_clz(x)
Which is trying to compute the most significant bit of 'x'. That's
actually the value computed directly by the 'bsr' instruction, but if we
match it too late, we'll get completely redundant xor instructions.
The more naive code for the above (subtracting rather than using an xor)
still isn't handled correctly due to the dagcombine getting confused.
Also, while here fix an issue spotted by inspection: we should have been
expanding the zero-undef variants to the normal variants when there is
an 'lzcnt' instruction. Do so, and test for this. We don't want to
generate unnecessary 'bsr' instructions.
These two changes fix some regressions in encoding and decoding
benchmarks. However, there is still a *lot* to be improve on in this
type of code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147244 91177308-0d34-0410-b5e6-96231b3b80d8
ARM targets with NEON units have access to aligned vector loads and
stores that are potentially faster than unaligned operations.
Add support for spilling the callee-saved NEON registers to an aligned
stack area using 16-byte aligned NEON loads and store.
This feature is off by default, controlled by an -align-neon-spills
command line option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147211 91177308-0d34-0410-b5e6-96231b3b80d8
My change r146949 added register clobbers to the eh_sjlj_dispatchsetup pseudo
instruction, but on Thumb1 some of those registers cannot be used. This
caused massive failures on the testsuite when compiling for Thumb1. While
fixing that, I noticed that the eh_sjlj_setjmp instruction has a "nofp"
variant, and I realized that dispatchsetup needs the same thing, so I have
added that as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147204 91177308-0d34-0410-b5e6-96231b3b80d8
The value from the operands isn't right yet, but we weren't encoding it at
all previously. The parser needs to twiddle the values when building the
instruction.
Partial for: rdar://10558523
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147170 91177308-0d34-0410-b5e6-96231b3b80d8
probability wouldn't be considered "hot" in some weird loop structures
or other compounding probability patterns. This makes it much harder to
confuse, but isn't really a principled fix. I'd actually like it if we
could model a zero probability, as it would make this much easier to
reason about. Suggestions for how to do this better are welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147142 91177308-0d34-0410-b5e6-96231b3b80d8
performance regressions (both execution-time and compile-time) on our
nightly testers.
Original commit message:
Fix for bug #11429: Wrong behaviour for switches. Small improvement for code
size heuristics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147131 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than require the symbol to be explicitly an argument of the directive,
allow it to look ahead and grab the symbol from the next non-whitespace
line.
rdar://10611140
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147100 91177308-0d34-0410-b5e6-96231b3b80d8
Diagnostics are now emitted via the SourceMgr and we use MemoryBuffer
for buffer management. Switched the code to make use of the trailing
'0' that MemoryBuffer guarantees where it makes sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147063 91177308-0d34-0410-b5e6-96231b3b80d8
call site of an intrinsic is also not an inline candidate. While here, make it
more obvious that this code ignores all intrinsics. Noticed by inspection!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147037 91177308-0d34-0410-b5e6-96231b3b80d8
DSHD (Double Swap Halfwords within Doublewords). Add a pattern which replaces
64-bit bswap with a DSBH and DSHD pair.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147017 91177308-0d34-0410-b5e6-96231b3b80d8
instruction supported by mips32r2, and add a pattern which replaces bswap with
a ROTR and WSBH pair.
WSBW is removed since it is not an instruction the current architectures
support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147015 91177308-0d34-0410-b5e6-96231b3b80d8
the build bot in some cases. The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type. It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext. We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.
Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is
pretty great that way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147010 91177308-0d34-0410-b5e6-96231b3b80d8
Use the spill slot alignment as well as the local variable alignment to
determine when the stack needs to be realigned. This works now that the
ARM target can always realign the stack by using a base pointer.
Still respect the ARMBaseRegisterInfo::canRealignStack() function
vetoing a realigned stack. Don't use aligned spill code in that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146997 91177308-0d34-0410-b5e6-96231b3b80d8
use the zero-undefined variants of CTTZ and CTLZ. These are just simple
patterns for now, there is more to be done to make real world code using
these constructs be optimized and codegen'ed properly on X86.
The existing tests are spiffed up to check that we no longer generate
unnecessary cmov instructions, and that we generate the very important
'xor' to transform bsr which counts the index of the most significant
one bit to the number of leading (most significant) zero bits. Also they
now check that when the variant with defined zero result is used, the
cmov is still produced.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146974 91177308-0d34-0410-b5e6-96231b3b80d8
Pulling the template implementation into the header to guarantee
that it's visible to all possible instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146973 91177308-0d34-0410-b5e6-96231b3b80d8
We used to rely on the *eh_sjlj_setjmp instructions to mark that a function
with setjmp/longjmp exception handling clobbers all the registers. But with
the recent reorganization of ARM EH, those eh_sjlj_setjmp instructions are
expanded away earlier, before PEI can see them to determine what registers to
save and restore. Mark the dispatchsetup instruction in the same way, since
that instruction cannot be expanded early. This also more accurately reflects
when the registers are clobbered.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146949 91177308-0d34-0410-b5e6-96231b3b80d8
"mov r1, r2, lsl #0" should assemble as "mov r1, r2" even though it's
not strictly legal UAL syntax. It's a common extension and the friendly
thing to do.
rdar://10604663
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146937 91177308-0d34-0410-b5e6-96231b3b80d8
merging types by name when we can. We still don't guarantee type name linkage
but we do it when obviously the right thing to do. This makes LTO type names
easier to read, for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146932 91177308-0d34-0410-b5e6-96231b3b80d8
unpredicated. That is, turn
subeq r0, r1, #1
addne r0, r1, #1
into
sub r0, r1, #1
addne r0, r1, #1
For targets where conditional instructions are always executed, this may be
beneficial. It may remove pseudo anti-dependency in out-of-order execution
CPUs. e.g.
op r1, ...
str r1, [r10] ; end-of-life of r1 as div result
cmp r0, #65
movne r1, #44 ; raw dependency on previous r1
moveq r1, #12
If movne is unpredicated, then
op r1, ...
str r1, [r10]
cmp r0, #65
mov r1, #44 ; r1 written unconditionally
moveq r1, #12
Both mov and moveq are no longer depdendent on the first instruction. This gives
the out-of-order execution engine more freedom to reorder them.
This has passed entire LLVM test suite. But it has not been enabled for any ARM
variant pending more performance evaluation.
rdar://8951196
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146914 91177308-0d34-0410-b5e6-96231b3b80d8
This change reduces the number of instructions generated.
For example,
(load (add (sub $n0, $n1), (MipsLo got(s))))
results in the following sequence of instructions:
1. sub $n2, $n0, $n1
2. lw got(s)($n2)
Previously, three instructions were needed.
1. sub $n2, $n0, $n1
2. addiu $n3, $n2, got(s)
3. lw 0($n3)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146888 91177308-0d34-0410-b5e6-96231b3b80d8
Now that getMatchingSuperRegClass() returns accurate results, it can be
used to compute constraints imposed by instructions using a sub-register
of a virtual register.
This means we can recompute the register class of any virtual register
by combining the constraints from all its uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146874 91177308-0d34-0410-b5e6-96231b3b80d8
Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().
Delete the old manual, error-prone implementations in the targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146873 91177308-0d34-0410-b5e6-96231b3b80d8
internal nightly testers. Original commit message:
By popular demand, link up types by name if they are isomorphic and one is an
autorenamed version of the other. This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large
app.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146838 91177308-0d34-0410-b5e6-96231b3b80d8
For example,
if (a == b) {
if (a > b) // this is false
Fixes some of the issues on <rdar://problem/10554090>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146822 91177308-0d34-0410-b5e6-96231b3b80d8
"half precision" floating-point with a first-class type.
This patch adds basic IR support (but not codegen support).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146786 91177308-0d34-0410-b5e6-96231b3b80d8
pointer or a reference type - we actually just want the size of the
pointer then for that.
Fixes rdar://10335756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146785 91177308-0d34-0410-b5e6-96231b3b80d8
The bad sorting caused a misaligned basic block when building 176.vpr in
ARM mode.
<rdar://problem/10594653>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146767 91177308-0d34-0410-b5e6-96231b3b80d8
This adjustment is already included in the block offsets computed by
BasicBlockInfo, and adjusting again here can cause the pass to loop.
When CreateNewWater splits a basic block, OffsetIsInRange would reject
the new CPE on the next pass because of the too conservative alignment
adjustment. This caused the block to be split again, and so on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146751 91177308-0d34-0410-b5e6-96231b3b80d8
The command line option should be removed, but not until the feature has
gotten a lot of testing. The ARMConstantIslandPass tends to have subtle
bugs that only show up after a while.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146739 91177308-0d34-0410-b5e6-96231b3b80d8
autorenamed version of the other. This makes the IR easier to read, because
we don't end up with random renamed versions of the types after LTO'ing a large app.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146728 91177308-0d34-0410-b5e6-96231b3b80d8
the compact unwind claiming that one register was saved before another, which
isn't all that great in general. Process them in the natural order. Reverse the
list only when necessary for the algorithm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146612 91177308-0d34-0410-b5e6-96231b3b80d8
into Analysis as a standalone function, since there's no need for
it to be in VMCore. Also, update it to use isKnownNonZero and
other goodies available in Analysis, making it more precise,
enabling more aggressive optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146610 91177308-0d34-0410-b5e6-96231b3b80d8
An aligned constant pool entry may require extra alignment padding where
the new water is created. Take that into account when computing offset.
Also consider the alignment of other constant pool entries when
splitting a basic block. Alignment padding may make it necessary to
move the split point higher.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146609 91177308-0d34-0410-b5e6-96231b3b80d8
On ARM, peephole optimization for ABS creates a trivial cfg triangle which tempts machine sink to sink instructions in code which is really straight line code. Sometimes this sinking may alter register allocator input such that use and def of a reg is divided by a branch in between, which may result in extra spills. Now mahine sink avoids sinking if final sink destination is post dominator.
Radar 10266272.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146604 91177308-0d34-0410-b5e6-96231b3b80d8
In addition to improving the representation, this adds support for assembly
parsing of these instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146588 91177308-0d34-0410-b5e6-96231b3b80d8
r0 = mov #0
r0 = moveq #1
Then the second instruction has an implicit data dependency on the first
instruction. Sadly I have yet to come up with a small test case that
demonstrate the post-ra scheduler taking advantage of this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146583 91177308-0d34-0410-b5e6-96231b3b80d8
Work in progress. Parsing for non-writeback, single spaced register lists
works now. The rest have the representations better factored, but still
need more to be able to parse properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146579 91177308-0d34-0410-b5e6-96231b3b80d8
When 'cmp rn #imm' doesn't match due to the immediate not being representable,
but 'cmn rn, #-imm' does match, use the latter in place of the former, as
it's equivalent.
rdar://10552389
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146567 91177308-0d34-0410-b5e6-96231b3b80d8
to finalize MI bundles (i.e. add BUNDLE instruction and computing register def
and use lists of the BUNDLE instruction) and a pass to unpack bundles.
- Teach more of MachineBasic and MachineInstr methods to be bundle aware.
- Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to
prevent IT blocks from being broken apart.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146542 91177308-0d34-0410-b5e6-96231b3b80d8
Fast ISel isn't able to handle 'insertvalue' and it causes a large slowdown
during -O0 compilation. We don't necessarily need to generate an aggregate of
the values here if they're just going to be extracted directly afterwards.
<rdar://problem/10530851>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146481 91177308-0d34-0410-b5e6-96231b3b80d8
test cases where there were a lot of relocations applied relative to a large
rodata section. Gas would create a symbol for each of these whereas we would
be relative to the beginning of the rodata section. This change mimics what
gas does.
Patch by Jack Carter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146468 91177308-0d34-0410-b5e6-96231b3b80d8
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.
Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.
Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146466 91177308-0d34-0410-b5e6-96231b3b80d8
Constant pool entries with different alignment may cause more alignment
padding to be inserted. Compute the amount of padding needed, and try to
pick the location that requires the least amount of padding.
Also take the extra padding into account when the water is above the
use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146458 91177308-0d34-0410-b5e6-96231b3b80d8
This should always be done as a matter of principal. I don't have a
case that exposes the problem. I just noticed this recently while
scanning the code and realized I meant to fix it long ago.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146438 91177308-0d34-0410-b5e6-96231b3b80d8
subdirectories to traverse into.
- Originally I wanted to avoid this and just autoscan, but this has one key
flaw in that new subdirectories can not automatically trigger a rerun of the
llvm-build tool. This is particularly a pain when switching back and forth
between trees where one has added a subdirectory, as the dependencies will
tend to be wrong. This will also eliminates FIXME implicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146436 91177308-0d34-0410-b5e6-96231b3b80d8
If we create new intervals for a variable that is being spilled, then those new intervals are not guaranteed to also spill. This means that anything reading from the original spilling value might not get the correct value if spills were missed.
Fixes <rdar://problem/10546864>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146428 91177308-0d34-0410-b5e6-96231b3b80d8
These modifiers simply select either the low or high D subregister of a Neon
Q register. I've also removed the unimplemented 'p' modifier, which turns out
to be a bit different than the comment here suggests and as far as I can tell
was only intended for internal use in Apple's version of gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146417 91177308-0d34-0410-b5e6-96231b3b80d8
detected in the forward-CFG DFS. This prevents the reverse-CFG from
visiting blocks inside loops after blocks that dominate them in the
case where loops have multiple exits.
No testcase, because this fixes a bug which in practice only shows
up in a full optimizer run, due to the use-list order.
This fixes rdar://10422791 and others.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146408 91177308-0d34-0410-b5e6-96231b3b80d8
Downgrade the alignment of the initial constant island when constant
pool entries are moved elsewhere.
This is all gated by -arm-align-constant-islands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146391 91177308-0d34-0410-b5e6-96231b3b80d8
Order constant pool entries by descending alignment in the initial
island to ensure packing and correct alignment. When the command line
flag is set, also align the basic block containing the constant pool
entries.
This is only a partial implementation of constant island alignment. More
to come.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146375 91177308-0d34-0410-b5e6-96231b3b80d8
indicates whether the intrinsic has a defined result for a first
argument equal to zero. This will eventually allow these intrinsics to
accurately model the semantics of GCC's __builtin_ctz and __builtin_clz
and the X86 instructions (prior to AVX) which implement them.
This patch merely sets the stage by extending the signature of these
intrinsics and establishing auto-upgrade logic so that the old spelling
still works both in IR and in bitcode. The upgrade logic preserves the
existing (inefficient) semantics. This patch should not change any
behavior. CodeGen isn't updated because it can use the existing
semantics regardless of the flag's value.
Note that this will be followed by API updates to Clang and DragonEgg.
Reviewed by Nick Lewycky!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146357 91177308-0d34-0410-b5e6-96231b3b80d8
The OptLevel is now redundant with the TargetMachine*.
And selectTarget() isn't really JIT-specific and could probably
get refactored into one of the lower level libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146355 91177308-0d34-0410-b5e6-96231b3b80d8
The split point is picked such that the newly created water has the same
alignment as the function. This makes the island suitable for constant
pool entries with potentially higher alignment.
This also fixes an issue where the basic block was split one instruction
too late, causing nonconvergence of the algorithm.
<rdar://problem/10550705>
There is still an issue with correctly packing differently aligned
entries in the island.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146314 91177308-0d34-0410-b5e6-96231b3b80d8
does. The _GLOBAL_OFFSET_TABLE_ is still magical in that we get a R_386_GOTPC,
but it doesn't change the immediate in the same way as when the expression
has no right hand side symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146311 91177308-0d34-0410-b5e6-96231b3b80d8
Since we're not rewriting IVs in other loops, there's not much reason
to consider their stride when generating formulae.
This should reduce the number of useless formulas considered by LSR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146302 91177308-0d34-0410-b5e6-96231b3b80d8
Backwards compatibility with 'gas'. #imm is the preferered and documented
syntax, but lots of existing code uses the '$' prefix, so we should
support it if we can.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146285 91177308-0d34-0410-b5e6-96231b3b80d8