[LLVMdev] RFC: SDNode Flags

Dan Gohman gohman at apple.com
Mon Aug 3 15:10:47 PDT 2009


On Aug 3, 2009, at 12:20 PM, David Greene wrote:


> On Monday 03 August 2009 12:38, Dan Gohman wrote:
>
>
>>> *shudder*  Undefined behavior?  No thanks.
>>>
>>
>>
>> What undefined behavior?  Is it PointerIntPair that's making you
>>
>> shudder?
>>
>> That's implementation-defined behavior. Very different :-).  And it's
>>
>> checked
>>
>> by asserts.
>>
>
> Well, it's still non-portable either way.

LLVM does many non-portable things behind encapsulation.

>
>
>
>>> What do you think about carving four more bits out of the alignment
>>>
>>> field
>>>
>>> so we have five flag/semantic bits and can represent alignments up
>>>
>>> to 2^64?
>>>
>>> That seems like plenty of alignment headroom.
>>>
>
>
>> Yes, that's fine too.  If someone really wanted an alignment greater
>>
>> than 1<<64, they would probably have other issues that would dwarf
>>
>> this one.
>>
>
> But see Evan's note.  I can see a need for more bits if we take
> target-specific needs into account.  I'll work on a solution.

Ok.

>
>
>>>> How are you representing movnt in LLVM IR, with an intrinsic?
>>>>
>>>
>>>
>>> Yes, it's an intrinsic inserted just before the load or store of
>>>
>>> interest.
>>>
>>> I'm not particularly happy with this solution because I'm not sure  
>>> all
>>>
>>> transformation passes will preserve the ordering of
>>>
>>> intrinsic-followed-by-operation.  Is there a better way to do this?
>>>
>>
>>
>> Crazy idea: how about an intrinsic just after the load or store of
>>
>> interest?
>>
>> It would be a sort of opposite of prefetch, saying "i'm not going  
>> to be
>>
>> using the memory at this address for a while".   It could use
>>
>> IntrWriteArgMem like the regular prefetch does, which is usually
>>
>> sufficient to keep it from wandering off, though it is a little
>>
>> stronger than
>>
>> is strictly necessary.
>>
>
> Does before vs. after matter for IntrWriteArgMem?

After just seems a little more intuitive:
   "I won't be using the memory at this address for a while."
rather than
   "I'm about to do a store to this address and after that I won't be
    using the memory there for a while."

>  What does that do anyway?

Passes that don't know about that specific intrinsic will treat it
as if it reads from and writes to the memory pointed to by its
argument.

>
>
>> The other alternative is something like llvm.x86.sse.movnt.ps and
>>
>> friends.
>>
>
> I don't want to go that route because this kind of information is  
> useful on
> multiple targets.  Better to have one way to do it.  We ain't coding  
> Perl
> here.  :)

A target-independent intrinsic that would be lowered to a plain
store on targets which don't have special instructions would be possible
too. I'm not necessarily advocating this, just mentioning the  
possibility.

Dan




More information about the llvm-dev mailing list