[LLVMdev] Let's get rid of neverHasSideEffects

Evandro Menezes emenezes at codeaurora.org
Wed Sep 5 09:32:09 PDT 2012


Jakob,

That's great!  I'll add this as part of my efforts refactoring the 
Hexagon insn table.

BTW, I think that I came about your way modifying it.  I think that only 
after going a little further some of your remarks made about my initial 
approach.  I'm using an approach that doesn't hinder multi-classes anymore.

Thanks,

-- 
Evandro Menezes          Austin, TX          emenezes at codeaurora.org
Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum


On 08/24/12 18:33, Jakob Stoklund Olesen wrote:
>
> On Aug 22, 2012, at 9:40 AM, Evandro Menezes <emenezes at codeaurora.org> wrote:
>
>> On 08/21/12 16:49, Jim Grosbach wrote:
>>>
>>> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred.
>>>
>>> Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :(
>>
>> This proposal would certainly make my life easier by having an easier to maintain insn table.
>>
>> For instance, we had to create two store insn classes: one which defined mayStore and one that didn't.  The former was to be used when an insn had no pattern and the latter, when mayStore was implied in the pattern.
>>
>> If only TableGen wouldn't warn about non-conflicting attributes at least…
>
> That warning has been removed now, and you should be able to clean up your classes.
>
> I also filed PR13693 for you. It's a bug to lower atomic_load to an instruction without mayStore - atomic loads can't be reordered.
>
> /jakob
>



More information about the llvm-dev mailing list