gcc-7-20190221 is now available
Snapshot gcc-7-20190221 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190221/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 269078 You'll find: gcc-7-20190221.tar.xzComplete GCC SHA256=27cb18229743b82800a95f6e3d83fccb6786b7519c126466da647cc886d7a795 SHA1=33b44944adddf6071720d6d4efdfe9b41853bcf7 Diffs from 7-20190214 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Question regarding constraint usage within inline asm
On 2/20/19 9:39 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 08:57:52PM -0600, Peter Bergner wrote:
>> Yes, because they don't have my IRA and LRA patches that exposed this
>> problem. I would say they were buggy for not complaining and silently
>> spilling a hard register in the case where we used asm reg("...").
>
> I don't follow your reasoning. It seems to me that giving some
> variable a register asm doesn't mean that the value of that variable
> can't appear in some other register. An obvious example is when
> passing that variable to a function.
I don't disagree with you here. For sure, multiple registers can hold
the same value, the same that multiple variables can hold the same value.
> So why shouldn't a hard reg be reloaded in order to satisfy
> incompatible constraints?
About the only usage of register asm that is guaranteed, is their
usage in inline asm. If you specify a hard register for a variable
and then use that variable in an inline asm, you are guaranteed
that that variable will use that register in the inline asm.
Now in this case, "input" doesn't have the register asm, but
asmcons rewrites the rtl such that it looks like "input" was
assigned via a register asm.
LRA doesn't know about register asms, it just sees pseudos and hard
registers, so I think it needs to be conservative and assume the
explicit hard registers it sees could have come from a register asm,
and not spill it, but rather error out and let the user fix it.
That said, the "bug" in the case we're seeing, is that asmcons
rewrote all of "input"'s pseudos, and it should be more careful
to not create rtl with illegal constraint usage that LRA cannot
fix up. With the fix, operand %1 in the inline asm is no longer
hard coded to r3 and it uses the pseudo instead, so everything
is copacetic.
Peter
アラート：別のデバイスからログインしたApple IDログイン.
親愛なるCIient、gcc@gcc.gnu.org セキュリティ上の理由から、Apple IDはロックされています。 誰かが新しいデバイスであなたのApple IDを悩ませました 日付：2019年2月22日、 ブラウザ：Chrome オペレーティングシステム：Windows AppleのIDを引き続き使用するには、アカウントを確認する必要があります。 確認するにはここをクリック 心からあなたの, サポート Apple ID Apple|サポート|プライバシーポリシー 著作権 (c) 2019Apple 流通国際,Hollyhill Industrial Estate, Hollyhill, Cork, Ireland.すべての権利を保有.
Re: Question regarding constraint usage within inline asm
On Thu, Feb 21, 2019 at 05:16:48PM -0600, Peter Bergner wrote: > About the only usage of register asm that is guaranteed, is their > usage in inline asm. If you specify a hard register for a variable > and then use that variable in an inline asm, you are guaranteed > that that variable will use that register in the inline asm. Yup. > That said, the "bug" in the case we're seeing, is that asmcons > rewrote all of "input"'s pseudos, and it should be more careful > to not create rtl with illegal constraint usage that LRA cannot > fix up. With the fix, operand %1 in the inline asm is no longer > hard coded to r3 and it uses the pseudo instead, so everything > is copacetic. And that expand used one pseudo for everything in the asm is bad already. If two inputs have identical constraints, sure, then it makes sense perhaps (but does it really safe anything anyway?) Otherwise it does not. Segher
