[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"
Robison, Arch
arch.robison at intel.com
Wed Aug 20 13:54:10 PDT 2014
> I thought the idea was to add it to every load/store in the loop. If
> this loop then gets fused with another, or inlined/unrolled becoming
> part of another loop, etc., wouldn't those ids conflict?
Handling inlining correctly would seem to require that front-ends mark the
lexical position of call sites as well as memory accesses, so that inlined
accesses could be given their proper context information. The rule
applies recursively down the call chain from a simd loop. If an inliner
encounters an unmarked access, it inlines it as unmarked, causing
vectorization to fail safe if dependence analysis can't figure it out.
If the lexical position markers were conceptually strings of integers,
the inlining bookkeeping might be simpler. E.g., given a call site
with position string A, and a callee instruction with position string
B, the inlined instruction would have string AB. A list
representation of the strings (with shared tails) could keep the memory
requirements down.
The conceptual string representation might simplify bookkeeping for
concatenation unrolling too, but I haven't worked out the details.
- Arch D. Robison
Intel Corporation
More information about the llvm-dev
mailing list