The failures in r116753 r116756 were caused by a python issue -
Python likes to append 'L' suffix to stringified numbers if the number
is larger than a machine int. Unfortunately, this causes a divergence of
behavior between 32 and 64 bit python versions.
I re-crafted elf-dump/common_dump to take care of these issues by:
1. always printing 0x (makes for easy sed/regex)
2. always print fixed length (exactly 2 + numBits/4 digits long)
by mod ((2^numBits) - 1)
3. left-padded with '0'
There is a residual common routine that is also used by
macho-dump (dataToHex) , so I left the 'section_data' test values alone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116823 91177308-0d34-0410-b5e6-96231b3b80d8
"long latency" enough to hoist even if it may increase spilling. Reloading
a value from spill slot is often cheaper than performing an expensive
computation in the loop. For X86, that means machine LICM will hoist
SQRT, DIV, etc. ARM will be somewhat aggressive with VFP and NEON
instructions.
- Enable register pressure aware machine LICM by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116781 91177308-0d34-0410-b5e6-96231b3b80d8
word forms and suffixed versions to match the darwin assembler in 32-bit and
64-bit modes. This is again for use just with assembly source for llvm-mc .
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116773 91177308-0d34-0410-b5e6-96231b3b80d8
does normal initialization and normal chaining. Change the default
AliasAnalysis implementation to NoAlias.
Update StandardCompileOpts.h and friends to explicitly request
BasicAliasAnalysis.
Update tests to explicitly request -basicaa.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116720 91177308-0d34-0410-b5e6-96231b3b80d8
be more complete. These are only expected to be used by llvm-mc with assembly
source so there is no pattern, [], in the .td files. Most are being added to
X86InstrInfo.td as Chris suggested and only comments about register uses are
added. Suggestions welcome on the .td changes as I'm not sure on every detail
of the x86 records. More missing instructions will be coming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116716 91177308-0d34-0410-b5e6-96231b3b80d8
The old algorithm inserted a 'rotqmbyi' instruction which was
both redundant and wrong - it made shufb select bytes from the
wrong end of the input quad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116701 91177308-0d34-0410-b5e6-96231b3b80d8
single object format can be shared.
This also adds support for
mov zed+(bar-foo), %eax
on ELF and COFF targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116675 91177308-0d34-0410-b5e6-96231b3b80d8
have been printed with the "S" modifier after the predicate. With ARM's
unified syntax, they are supposed to go in the other order. We fixed this
for Thumb when we switched to unified syntax but missed changing it for
ARM. Apparently we don't generate these instructions often because no one
noticed until now. Thanks to Bill Wendling for the testcase!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116563 91177308-0d34-0410-b5e6-96231b3b80d8
here. The f32 in FCONSTS is handled as a double instead of a float in the
code. So the encoding of the immediate into the instruction isn't exactly in
line with the documentation in that regard. But given that we know it's handled
as a double, it doesn't cause any harm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116471 91177308-0d34-0410-b5e6-96231b3b80d8
logic to use the new APInt methods. Among other things this
implements rdar://8501501 - llvm.smul.with.overflow.i32 should constant fold
which comes from "clang -ftrapv", originally brought to my attention from PR8221.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116457 91177308-0d34-0410-b5e6-96231b3b80d8
and handle the operand explicitly. Flesh out encoding information. Add an
explicit disassembler testcase for the instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116432 91177308-0d34-0410-b5e6-96231b3b80d8
