[LLVMdev] Let's get rid of neverHasSideEffects

Chris Lattner clattner at apple.com
Wed Aug 22 14:37:07 PDT 2012


On Aug 22, 2012, at 2:26 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Aug 21, 2012, at 4:41 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> Personally, I don't like the direction of making everything be redundantly specified with "let" clauses and in the patterns.  I agree that it is a problem that we're not inferring from Pat<> patterns, and that not all instructions are expressible with patterns, but I'd rather we solve *those* problems than throw out inference.
> 
> After discussing this, we have reached a workable compromise. Here's what we'll do:
> 
> The inferred instruction properties will become tristate and default to Unset:
> 
>  bit hasSideEffects = ?;
>  bit mayLoad = ?;
>  bit mayStore = ?;
> 
> TableGen will attempt to infer these properties from any instruction patterns.
> 
> If inference fails and a property is unset, TableGen will issue an error instead of guessing.
> 
> If inference succeeds and a property is set to an inconsistent value, TableGen will issue an error.
> 
> If inference succeeds and a property is set to a consistent value, TableGen will happily and silently go about its business.
> 
> This will also handle migration for out-of-tree targets. They can replace 'neverHasSideEffects = 1' with 'hasSideEffects = 0', and any instructions without patterns will be pointed out for audit.

Sounds great, thanks Jakob.  Notably, this should also remove unnecessary complexity in the .td files that stems from tblgen *refusing* instructions that have an explicitly set property that it was also able to infer.  I'm also in favor of making tblgen stop rejecting things like "(add imm, reg)" which are non-canonical, but come up with multi-patterns.  It is better to have isel ignore the pattern than to have it generate an error, forcing crazy factoring of patterns to avoid the error.

-Chris



More information about the llvm-dev mailing list