[LLVMdev] LLVM Loop Vectorizer

[Nick Lewycky]

Nadav Rotem wrote:
>
> On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca
> <mailto:nicholas at mxc.ca>> wrote:
>
>> I absolutely think that we should have something like TargetData (now
>> DataLayout) but for the vector types and operations. However, I'm not
>> familiar with "Target Lowering Interface". Could you explain?
>
> I agree. Once we make the codegen accessible to the IR-level passes we
> need to start talking about the right abstraction. I have some ideas,
> but I wanted to start the discussion after we are done with the first
> phase.
>
> Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the
> TLI interface which can answer questions such as "is this operation
> supported ?" or "is this type legal". This is a subset of what we need
> in a vectorized. We can discuss other requirements that the vectorizer
> may have after we finish with the first phase. I suspect that we may
> have to refactor some functionality out of TLI.

Okay, if you're referring to llvm::TargetLowering, then yes that should 
have a whole slew of methods copied out to a new object (I'm imagining 
TargetVectorData with a getter in TargetData) that would answer those 
questions.

Exposing TargetLowering itself is a bad idea since its interface refers 
to MCExpr* and SDValue and other things that genuinely don't make sense 
at the IR level.

>> Currently TLI is only available in LLC. I suggest that we merge LLC
>> and OPT into a single tool that will drive both IR-level passes and
>> the codegen.
>>
>> This really shouldn't be necessary. Notably, it is still possible
>> today to build a Module and optimize it without having decided what
>> target you're targeting.
>
> I agree that it is not necessary for many optimizations. However, this
> is absolutely needed for lower-level transformations such as strength
> reduction. So, I plan to keep the current behavior that OPT has where if
> a target information is not provided through the command line then
> TargetData is kept uninitialized (null pointer). So, as far as IR-level
> passes go, nothing is going to change.

How much do you like the way TargetData works? With the strings in the 
module? It has the benefit of having a working design which means you 
won't get much noise about it in review.

The downside is that all the information that goes into the 
TargetVectorData would have to be be encoded as a string and put into 
the Module. You'll have to invent an encoding and write a parser for it. 
Yuck.

The upside is that it preserves the IR / codegen distinction that we've 
all grown to love, and does it using a mechanism that is in LLVM terms 
as old as the hills. No reviewer could argue that.

I was imagining a new "target vectorunit = "..."" string in the modules. 
If you want a different way of doing it for the vector information, I 
might ask that you change how TargetData works too. :)

Nick