> From: Eric Christopher [echri...@gmail.com] > Sent: 06 January 2015 00:00 > To: Toma Tabacu; Daniel Sanders > Cc: cfe-commits@cs.uiuc.edu > Subject: Re: [PATCH] [mips] Always clobber $1 for MIPS inline asm. > > 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 $a > > 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 We could stop using $at but why is that beneficial? Why does universally reserving a register to support an (uncommon) construct make more sense to you than having that construct properly indicate that it may clobber a specific register? The former sounds like a sledgehammer to me. The work pre-dates me but as far as I can tell the developers of the Mips port deliberately decided not to reserve $at and emit code in '.set noat' mode. Presumably this was to see how much of gcc's $at usage is essential to the correct operation of the output code. It turns out that the answer is 'almost none'. In LLVM's CodeGen, $at isn't particularly special. The few instructions/macros/relocations that need a temporary register to be $at describe this with an implicit def of AT. Branches like B are a good example of this (it's worth pointing out that most of the time we don't really need to clobber $at since the branch target will be in range). Where the temporary doesn't really need to be $at, we just ask the register allocator to give us any register. The hard work to avoid reserving $at is already done and I don't see a good reason to change the original decision. _______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
