[LLVMdev] Status of pre-legalize vector changes

Chris Lattner sabre at nondot.org
Wed Jun 13 11:00:49 PDT 2007


On Wed, 13 Jun 2007, Dan Gohman wrote:
>> Note that this change is logically independent of the rest of your change,
>> so you could do this on mainline, as a first step to getting the bigger
>> change in.
>
> Ok, these are now created. The new opcodes aren't very general yet; currently
> they're only suitable for pre-legalize use; they're only currently needed for
> lowering CopyToReg and CopyFromReg. Once the rest of the pre-legalize vector
> changes go in, these opcodes will loose the leading 'V' in their names, and
> then it'll be easier to extend them to other purposes.

Very nice, the patches look very clean and one more hack is dead :)

>> The problem with this approach is that it makes it much harder to codegen
>> two different functions in parallel on different threads.  This isn't
>> something we do today, but is something we want to do eventually.
>> Requiring synchronization in such a critical datastructure would be
>> badness...
>
> The badness could be mitigated somewhat with readers-writer locks, because
> the common case for this table would be that it would get a few entries added
> to it right away and then see very few updates, if any, for the rest of its
> lifetime.

True, but you still have cache lines bouncing around between processors 
:).  It's just much better to completely eliminate sharing when possible, 
particularly when the data structures are logically separate.

> I'll take another look at eliminating the static table though.

Thanks.  If it gets too nasty, I can be convinced, but it would be very 
nice to keep these separated.

>> That said, I don't know just how horrible the impact is on the code.
>> Maybe there is another way?  Maybe the value table should be a first class
>> datastructure that SelectionDAG contains.  This would let you do things
>> like:
>>
>> SD.getValueTable().getNumVectorElements(VT)
>>
>> but it would also allow clients to grab a reference to the valuetable and
>> call into it directly if more convenient.  Would this help at all?
>
> Not really. The problem I saw was clients that don't have the SelectionDAG
> passed into them. Passing around handles to this new kind of object everywhere
> wouldn't be any easier than passing around handles to the DAG itself.

Ok.

>> One nice thing about this is that the ValueTable datastructure would be
>> very simple, and moving all the methods to operate on a value table would
>> be straight-forward.  If ValueTable was a simple class, then tblgen could
>> instantiate it (f.e.) and not populate it with any of the funny MVT's.
>
> You mean like MVT::iAny? Those are still just simple enum values; they don't
> live in the table.

I just mean that *all* MVT related functions could turn into methods on 
the valuetable for consistency.  Right now we have this weird dichotomy 
between the MVTs that tblgen uses and the MVTs that the codegen stuff 
uses.  tblgen can only use a subset of the functions, it would be nice to 
eliminate that, but not very important in the grand scheme of things.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/



More information about the llvm-dev mailing list