[LLVMdev] Vectorizer using Instruction, not opcodes

[Renato Golin]

Hi folks,

I've been thinking on how to implement some of the costs and there is a lot
of instructions which cost depend on other instructions around. Casts are
one obvious case, since arithmetic and memory instructions can, sometimes,
cast values for free.

The cost model receives Opcodes, which lose the info on the history of the
values being vectorized, and I thought we could pass the whole Instruction
instead. But this is the easy part... Below are some  ideas which I'd love
to hear from you guys which makes sense and which doesn't...

A. How to find context?

Suppose you have a cast instruction, and you want to find out if there is
an arithmetic operations before (or after) on any of the values it
touches...

%3 = sext %type1 %2 to %type2

You could iterate through all uses of %3 and %2 and see if any of them is a
mul/add/sub, and return 'true', so that the cost would add (or not) an
extra cycle.

Problems:

1. This space is multi-dimensional, ie. there are many types in and many
out, and the cost table is not linear on any of the dimensions (hence, cost
tables). An idea is to create a multi-dimension cost table, but that could
get confusing really quickly.

2. We're essentially reproducing the logic of Inst Combine, which is not
sensible nor appropriate.

Any ideas on direction for this one?


B. How to find resulting code?

Another alternative is to run some lower level passes on the code, to
reduce the chances that we're guessing in the dark, but that'd be extremely
expensive. Maybe we can only run the vectorizer at the very end, and only
if code changed, that we'd re-ruin again the clean-up passes. I'm not
convinced...


C. Settle for guess in the dark

We can continue guessing in the dark, but do it consistently. This is our
approach, and I'm, wondering if it makes sense to deviate from it.

My main issue is that the costs for ARM instructions are almost random when
seen from an IR perspective, we're bound to make as many mistakes as not.

Another issue is that the number of vector IR instructions (extract/select)
is a lot more than the resulting vector code, and that can count negatively
on the benefits of vectorizing.


It's also quite possible that I'm over-thinking...

Thoughts?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130204/9edd894d/attachment.html>