[llvm-commits] Re: llvm-commits Digest, Vol 18, Issue 43

Chris Lattner sabre at nondot.org
Mon Dec 26 19:09:15 PST 2005

On Mon, 26 Dec 2005, Andrew Lenharth wrote:
>> I'm not sure I follow.  If this is fixed by the architecture (seems
>> unlikely for alpha but...) you should be able to do something like this:
>> (set R27, (fooop GPRC:$in1, GPRC:$in2))
> This works?  That is about what I need.

Yes, assuming foo-op is an operation with one result, this will emit the 
logical equivalent of:

  (set GPRC:$tmp, (fooop GPRC:$in1, GPRC:$in2))
  (copytoreg R27, $tmp)

... and flag them together.

>> it it is not fixed by the ISA, but fixed by the architecture, you should
>> handle this in the lowering code, and emit copyto/from regs.
> The problem is that because they are jumps and calls, the results of the
> operation must be in certain registers (and is visible in the called code).
> The dest reg is not fixed in the instruction, but in the calling conventions.

Yeah, I figured... it's not like alpha to hard code that stuff in :)

> Thus (Rd = BSR ...) has a calling convention specified reg for Rd, which is
> not specified in the architecture.  The hack is to fix it in the instruction
> used and issue a copyfromreg.

I'd suggest handling this in the lower code then.

> the closest I can get without that hack is (copyfromreg (copytoreg
> (bsr ...))), but that cannot be emitted as
> t = bsr
> Rd = t
> it must be
> Rd = bsr

> This requirement doesn't seem to be specified because I cannot specify the
> output regs for an instruction.

In practice, this will always be copy coallesced away.  I agree though 
that this feels hacky and shouldn't be done.

> I must encode the calling convention in the instruction descriptions. 
> If I wanted any other calling convention than linux alpha (which is the 
> same as Digital UNIX), I would have to have clones of those 
> instructions.  Probably not something worth worrying about because of 
> the alpha, but I could see it affecting other archs.

Yup, for alpha, coming back around to where we started, I guess it 
currently DOES make sense to encode the return reg into the instruction...



More information about the llvm-commits mailing list