[PATCH] [mips] Always clobber $1 for MIPS inline asm.

[Daniel Sanders]

> > > 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.
> -eric

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.

-eric


> > 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.
>
> -eric

Toma: Could you add a suitable comment to getClobbers()?

> http://reviews.llvm.org/D6638
_______________________________________________
cfe-commits mailing list
cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150113/716f3dbd/attachment.html>