[LLVMdev] Early-clobber constraint in TableGen

[David Greene]

On Tuesday 15 December 2009 19:52, Jim Grosbach wrote:

> Do you have specific examples in mind that would be expressible with
> something more complicated that aren't handleable via an early-clobber
> constraint?

Not offhand, no.  I'm mostly concerned about the readability of .td files.

> Perhaps spelling it out more fully with "earlyclobber" rather than
> "early" would help?

That's better.  Is there any way you could convince TableGen to recognize
that 'constraints = "$success != $src", "$success != $ptr"' is semantically
equivalent to earlyclobber?  Maybe check that the common operand in both
contraints is declared to interfere with all other operands and if that's
so, mark it earlyclobber.

When I'm writing .td files I really don't want to be concerned with the 
nitty-gritty details of how the backend is implemented.  I just want to 
express the semantics I want.  I think that was the motivation for the
switch from isThreeAddress to "$src = $dst."

I have no objection going with "earlyclobber" initially but we should think
about ways to abstract codegen semantics whenever we can.  If we can replace
"earlyclobber" with something clearer later on, all the better.  
"earlycloibber" is a really bad name, though.  Perhaps spell it "uniquereg"
or something else that gets at what it actually means?

It seems to me the root problem here is that the instruction has two outputs
and we don't want the output to be allocated to the same register as the
inputs.  We have no way to express multiple outputs in TableGen.

As it happens, AVX has similar problems with its semantics for VSQRTSS/SD.  In 
fact the semantics there are even worse, to the point where I'm not going to 
think any more about it.  :)

                            -Dave