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... -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum
Jakob Stoklund Olesen
2012-Aug-24 23:33 UTC
[LLVMdev] Let's get rid of neverHasSideEffects
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
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 >