[LLVMdev] Vectorizer using Instruction, not opcodes

[Arnold Schwaighofer]

Hi Hal,

On Feb 4, 2013, at 2:09 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Renato Golin" <renato.golin at linaro.org>
>> To: "Arnold Schwaighofer" <aschwaighofer at apple.com>
>> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com>, "Hal Finkel" <hfinkel at anl.gov>
>> Sent: Monday, February 4, 2013 1:38:03 PM
>> Subject: Re: Vectorizer using Instruction, not opcodes
>> 
>> 
>> On 4 February 2013 18:25, Arnold Schwaighofer <
>> aschwaighofer at apple.com > wrote:
>> 
>> For cases where this approach breaks really badly we could consider
>> adding a specialized api or parameters (like the type of a
>> user/use). But we should do so only as a last resort and backed by
>> actual code that would benefit from doing so.
>> 
>> 
>> Very sensible, more or less what I had in mind. I think we could go
>> one step further and just get some high-level decisions like: is
>> this cast associated with an (any) arithmetic operation? It won't be
>> perfect, but it adds a bit more information at very reduced price.
>> Though, this would require us to pass the Instruction, not the
>> Opcode.
>> 
> We probably don't want to end up in a situation where we're speculatively creating instructions just to test their cost using the cost model. For simple things, passing an existing instruction and its widening factor will work, but I worry that won't really be sufficiently general. Would a tree of <opcode, return-type, input-type>s work? How deep would it need to be?

Agreed, if we decide on more information than just type and opcode we will need some abstract representation.

> We also need to decide on some self-consistent way of dealing with cost folding. What I mean is that if an instruction can be folded with its use, do we register that cost savings for the use or the operand? We'd also need to pass hasOneUse() information.


I think this probably going to far, I don't think we want to model all of target lowering in the cost model. Any attempt would be a lie anyway ;). I don't think we should model at such a fine granularity at the IR level because any attempt of doing so is bound to fail.

- Arnold