In http://reviews.llvm.org/D6638#103013, @dsanders wrote:

> > > On Thu Dec 18 2014 at 1:21:53 PM Daniel Sanders 
> > > <daniel.sand...@imgtec.com<mailto:daniel.sand...@imgtec.com>> wrote:
>
> >  > > For the record, gcc does use $at for code generation, take a look at 
> > mips_print_operand for the @ symbol and then look at all of the cases it's 
> > being used.
>
> >  > That's correct. However, LLVM currently doesn't use $at for codegen and 
> > quite a bit of effort has been put in to making that the case. I'd like to 
> > retain this advantage over GCC if I can.
>
> >  That's not what the original mail said and there's no real reason to avoid 
> > using $at. I'm not sure I understand this rationale.
>
>
> I see where we're confusing you, Toma and I aren't being precise enough. In 
> GCC, $at is a reserved register. As you say, it does use $at in generated 
> code but as far as I know, it only does so as a very short lived temporary. 
> In LLVM, $at is an allocatable register and is freely used in all code 
> generation.


Yes...

> In GCC inline assembly, $at is still a reserved register and users have taken 
> advantage of this. In LLVM, $at needs to be clobbered by inline assembly so 
> that the users usage of $at doesn't break the compiler generated code.

> 

> > The point I was making is that the rationale for this patch is completely 
> > mistaken. i.e. gcc does use $at for code

> 

> >  generation so unless gcc is adding an implicit clobber of $at in inline 
> > asm then it's not going to be correct.

> 

> 

> GCC goes further than an implicit clobber. It has promised not to keep any 
> values in $at.


The idea behind the gcc usage is that anything that needs an explicit 
relocation or was a macro instruction before the demacroifying (yay, made up 
words) uses $at. We can definitely avoid using $at for anything in llvm, just 
pull it out of the register allocation pool?

I'm not sure where you're going with this?

-eric


http://reviews.llvm.org/D6638

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/



_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to