[PATCH] [mips] Always clobber $1 for MIPS inline asm.
Daniel.Sanders at imgtec.com
Tue Jan 13 06:49:17 PST 2015
> > > No, it's been known for a while that the use of macro instructions isn't a
> > > good idea in the compiler. It's why we switched the gcc port away from
> > > using them as well.
> > Out of curiosity, when did the switch happen? I thought it was emitting macros last time I looked (probably around June) but I could be mistaken.
> 2001/2002? At one point it emitted things like la, etc.
In that case it seems much more likely that I misread the cases I'm remembering. Maybe the mnemonic made it look like a macro but the operands used meant it was really a plain instruction.
From: Eric Christopher [mailto:echristo at gmail.com]
Sent: 07 January 2015 17:52
To: Daniel Sanders; reviews+D6638+public+9dbc664d9cbf7b31 at reviews.llvm.org; Toma Tabacu
Cc: cfe-commits at cs.uiuc.edu
Subject: Re: [PATCH] [mips] Always clobber $1 for MIPS inline asm.
On Wed Jan 07 2015 at 8:40:55 AM Daniel Sanders <Daniel.Sanders at imgtec.com<mailto:Daniel.Sanders at imgtec.com>> wrote:
> From: Eric Christopher [echristo at gmail.com<mailto:echristo at gmail.com>]
> Sent: 06 January 2015 20:15
> To: Toma Tabacu; Daniel Sanders
> Cc: cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
> Subject: Re: [PATCH] [mips] Always clobber $1 for MIPS inline asm.
> > 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.
> Totally is, but blindly adding clobbers is much the same, just a more
> focused hammer. I'm not against it, mostly that the original discussion
> didn't say any of these things.
Agreed. It's currently a compromise between precision and difficulty of implementation.
> > 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
> No, it's been known for a while that the use of macro instructions isn't a
> good idea in the compiler. It's why we switched the gcc port away from
> using them as well.
Out of curiosity, when did the switch happen? I thought it was emitting macros last time I looked (probably around June) but I could be mistaken.
2001/2002? At one point it emitted things like la, etc.
> > 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.
> Agreed. Please do make sure that the places where you need to do this are
> commented though. It's pretty poorly commented at the moment.
Toma: Could you add a suitable comment to getClobbers()?
cfe-commits mailing list
cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits