summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/LoopUnrollAndJam/unroll-and-jam.ll
diff options
context:
space:
mode:
authorAndrea Di Biagio <Andrea_DiBiagio@sn.scee.net>2018-11-25 12:46:24 +0000
committerAndrea Di Biagio <Andrea_DiBiagio@sn.scee.net>2018-11-25 12:46:24 +0000
commit36296c04843c5a7e5532c8058a2f06786f0bd027 (patch)
tree0aeb81a93828b9d55beebabd7c168bc5fda93e9e /llvm/test/Transforms/LoopUnrollAndJam/unroll-and-jam.ll
parent0631dae93b4490f55bad33cb68b5fead823da3ff (diff)
downloadbcm5719-llvm-36296c04843c5a7e5532c8058a2f06786f0bd027.tar.gz
bcm5719-llvm-36296c04843c5a7e5532c8058a2f06786f0bd027.zip
[llvm-mca] Add support for instructions with a variadic number of operands.
By default, llvm-mca conservatively assumes that a register operand from the variadic sequence is both a register read and a register write. That is because MCInstrDesc doesn't describe extra variadic operands; we don't have enough dataflow information to tell which register operands from the variadic sequence is a definition, and which is a use instead. However, if a variadic instruction is flagged 'mayStore' (but not 'mayLoad'), and it has no 'unmodeledSideEffects', then llvm-mca (very) optimistically assumes that any register operand in the variadic sequence is a register read only. Conversely, if a variadic instruction is marked as 'mayLoad' (but not 'mayStore'), and it has no 'unmodeledSideEffects', then llvm-mca optimistically assumes that any extra register operand is a register definition only. These assumptions work quite well for variadic load/store multiple instructions defined by the ARM backend. llvm-svn: 347522
Diffstat (limited to 'llvm/test/Transforms/LoopUnrollAndJam/unroll-and-jam.ll')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud