| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This code is no longer usefull, because we only compute and use the
IDom once. There is no benefit in caching it anymore.
llvm-svn: 205498
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector loads
When a vector type legalizes to a larger vector type, and the target does not
support the associated extending load (or truncating store), then legalization
will scalarize the load (or store) resulting in an associated scalarization
cost. BasicTTI::getMemoryOpCost needs to account for this.
Between this, and r205487, PowerPC on the P7 with VSX enabled shows:
MultiSource/Benchmarks/PAQ8p/paq8p: 43% speedup
SingleSource/Benchmarks/BenchmarkGame/puzzle: 51% speedup
SingleSource/UnitTests/Vectorizer/gcc-loops 28% speedup
(some of these are new; some of these, such as PAQ8p, just reverse regressions
that VSX support would trigger)
llvm-svn: 205495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r205479.
It turns out that nm does use addresses, it is just that every reasonable
relocatable ELF object has sections with address 0. I have no idea if those
exist in reality, but it at least it shows that llvm-nm should use the name
address.
The added test was includes an unusual .o file with non 0 section addresses. I
created it by hacking ELFObjectWriter.cpp.
Really sorry for the churn.
llvm-svn: 205493
|
|
|
|
|
|
|
|
|
| |
TargetInstrInfo::findCommutedOpIndices to enable VFMA*231 commutation, rather
than abusing commuteInstruction.
Thanks very much for the suggestion guys!
llvm-svn: 205489
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For an cast (extension, etc.), the currently logic predicts a low cost if the
associated operation (keyed on the destination type) is legal (or promoted).
This is not true when the number of values required to legalize the type is
changing. For example, <8 x i16> being sign extended by <8 x i32> is not
generically cheap on PPC with VSX, even though sign extension to v4i32 is
legal, because two output v4i32 values are required compared to the single
v8i16 input value, and without custom logic in the target, this conversion will
scalarize.
llvm-svn: 205487
|
|
|
|
|
|
|
|
| |
opportunities in the current basic block, rather than just the last one seen.
<rdar://problem/16478629>
llvm-svn: 205481
|
|
|
|
|
|
|
|
|
|
|
| |
What llvm-nm prints depends on the file format. On ELF for example, if the
file is relocatable, it prints offsets. If it is not, it prints addresses.
Since it doesn't really need to care what it is that it is printing, use the
generic term value.
Fix or implement getSymbolValue to keep llvm-nm working.
llvm-svn: 205479
|
|
|
|
|
|
|
|
|
|
| |
PPCTTI::getMemoryOpCost will now make use of BasicTTI::getMemoryOpCost to
calculate the base cost of the memory access, and then adjust on top of that.
There is no functionality change from this modification, but it will become
important so that PPCTTI can take advantage of scalarization information for which
BasicTTI::getMemoryOpCost will account in the near future.
llvm-svn: 205476
|
|
|
|
|
|
| |
performing unary constant folding operations (r204737).
llvm-svn: 205474
|
|
|
|
|
|
|
|
|
|
|
| |
on FMA3 memory operands. FMA3 instructions are VEX encoded, so they can load
from unaligned memory.
Testcase to follow, along with related patch.
<rdar://problem/16478629>
llvm-svn: 205472
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r199244.
Conflicts:
include/llvm-c/lto.h
include/llvm/LTO/LTOCodeGenerator.h
lib/LTO/LTOCodeGenerator.cpp
llvm-svn: 205471
|
|
|
|
|
|
| |
GetElementPtr opaque (r204739).
llvm-svn: 205468
|
|
|
|
|
|
|
| |
Update the subtarget information for Windows on ARM. This enables using the MC
layer to target Windows on ARM.
llvm-svn: 205459
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 205458
|
|
|
|
|
|
| |
There are no implementations of these for R600.
llvm-svn: 205455
|
|
|
|
|
|
|
|
| |
Just pass a MachineInstr reference rather than an MBB iterator.
Creating a MachineInstr& is the first thing every implementation did
anyway.
llvm-svn: 205453
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike other v6+ processors, cortex-m0 never supports unaligned accesses.
From the v6m ARM ARM:
"A3.2 Alignment support: ARMv6-M always generates a fault when an unaligned
access occurs."
rdar://16491560
llvm-svn: 205452
|
|
|
|
|
|
| |
No functional change, but more readable code.
llvm-svn: 205451
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the instructions ext/ext32/cins/cins32.
It also changes pop/dpop to accept the two operand version and
adds a simple pattern to generate baddu.
Tests for the two operand versions (including baddu/dmul/dpop/pop)
and the code generation pattern for baddu are included.
Reviewed by: Daniel.Sanders@imgtec.com
llvm-svn: 205449
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205446
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205445
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205444
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205443
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205442
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205441
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205440
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205439
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205438
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 205437
|
|
|
|
| |
llvm-svn: 205435
|
|
|
|
|
|
| |
Patch by Alex Crichton, ILyoan, Luqman Aden and Svetoslav.
llvm-svn: 205430
|
|
|
|
| |
llvm-svn: 205429
|
|
|
|
|
|
|
|
|
|
| |
Weak symbols cannot use the small code model's usual ADRP sequences since the
instruction simply may not be able to encode a value of 0.
This redirects them to use the GOT, which hopefully linkers are able to cope
with even in the static relocation model.
llvm-svn: 205426
|
|
|
|
|
|
|
| |
We were creating libcall nodes that returned an MVT::f128, when these
particular operations actually return an int of some stripe.
llvm-svn: 205425
|
|
|
|
|
|
|
|
|
| |
Some Intrinsics are overloaded to the extent that return type equality (all
that's been checked up to now) does not guarantee that the arguments are the
same. In these cases SLP vectorizer should not recurse into the operands, which
can be achieved by comparing them as "Function *" rather than simply the ID.
llvm-svn: 205424
|
|
|
|
|
|
|
|
| |
Again, coalescing and other optimisations swiftly made the MachineInstrs
consistent again, but when compiled at -O0 a bad INSERT_SUBREGISTER was
produced.
llvm-svn: 205423
|
|
|
|
|
|
|
|
| |
The previous attempt was fine with optimisations, but was actually rather
cavalier with its types. When compiled at -O0, it produced invalid COPY
MachineInstrs.
llvm-svn: 205422
|
|
|
|
| |
llvm-svn: 205421
|
|
|
|
| |
llvm-svn: 205416
|
|
|
|
|
|
|
|
|
| |
ARM specific optimiztion, finding places in ARM machine code where 2 dmbs
follow one another, and eliminating one of them.
Patch by Reinoud Elhorst.
llvm-svn: 205409
|
|
|
|
|
|
|
|
|
| |
and isTargetCygwin() to isTargetWindowsCygwin() to be consistent with the
four Windows environments in Triple.h.
Suggestion by Saleem Abdulrasool!
llvm-svn: 205393
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the purpose of calculating the cost of the loop at various vectorization
factors, we need to count dependencies of consecutive pointers as uniforms
(which means that the VF = 1 cost is used for all overall VF values).
For example, the TSVC benchmark function s173 has:
...
%3 = add nsw i64 %indvars.iv, 16000
%arrayidx8 = getelementptr inbounds %struct.GlobalData* @global_data, i64 0, i32 0, i64 %3
...
and we must realize that the add will be a scalar in order to correctly deduce
it to be profitable to vectorize this on PowerPC with VSX enabled. In fact, all
dependencies of a consecutive pointer must be a scalar (uniform), and so we
simply need to add all consecutive pointers to the worklist that currently
detects collects uniforms.
Fixes PR19296.
llvm-svn: 205387
|
|
|
|
|
|
|
|
| |
I'm not sure the comment in the implementation really adds a lot of
value (it's clear that we emit zero when no symbol is provided, but it
doesn't explain why we would do that). Happy to iterate.
llvm-svn: 205386
|
|
|
|
|
|
| |
Based on code review feedback from Eric Christopher on r204697
llvm-svn: 205385
|
|
|
|
|
|
|
|
|
|
|
|
| |
and an MC Label to refer to them
This removes the magic-number-esque code creating/retrieving the same
label for a debug_loc entry from two places and removes the last small
piece of reusable logic from emitDebugLoc so that there will be less
duplication when refactoring it into two functions (one for debug_loc,
the other for debug_loc.dwo).
llvm-svn: 205382
|
|
|
|
|
|
|
| |
framework works (for the compiler part), since the design
document is not available.
llvm-svn: 205379
|
|
|
|
| |
llvm-svn: 205374
|
|
|
|
|
|
|
|
|
|
| |
Seems we didn't have any test coverage for merging... awesome. So I
added some - but hit an llvm-objdump bug while I was there. I'm choosing
not to shave that yak right now.
Code review feedback/bug catch by Adrian Prantl in r205360.
llvm-svn: 205373
|
|
|
|
|
|
|
|
|
|
| |
No test case (this would invoke UB by examining uninitialized members,
etc, at best - and this code is apparently untested anyway - I'm about
to fix that)
Code review feedback from Adrian Prantl on r205360.
llvm-svn: 205367
|
|
|
|
| |
llvm-svn: 205365
|