[LLVMdev] Let's get rid of neverHasSideEffects
emenezes at codeaurora.org
Wed Sep 5 09:32:09 PDT 2012
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.
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.
More information about the llvm-dev