[LLVMdev] Vectorizer using Instruction, not opcodes

[David Tweed]

Hi,

The other thing I've thought about is that the "total cost of conversions"
ought to go through some sort of non-linear mapping based on the number of
instructions, so that the same "conversion cost" for a long inner loop gets
weighted less than for a short inner loop, since the more instructions there
are the more an out-of-order CPU can put them into otherwise unused slots. I
can't think of a way of figuring out such a mapping other than empirically.

Cheers,
Dave

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Arnold Schwaighofer
Sent: 04 February 2013 20:45
To: Hal Finkel
Cc: LLVM Dev
Subject: Re: [LLVMdev] Vectorizer using Instruction, not opcodes

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
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev