On Tue, 9 Aug 2011, Richard Earnshaw wrote:
> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements.
Only for those asm statements taking the same asm-register
variables as arguments.
> At ot
On Tue, 9 Aug 2011, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>
> > Better still would be to change the specification and implementation of
> > local register variables to only guarantee them at the beginning of ASM
> > statements. At other times they are simply the same as other local
> > v
Richard Earnshaw wrote:
> Better still would be to change the specification and implementation of
> local register variables to only guarantee them at the beginning of ASM
> statements. At other times they are simply the same as other local
> variables. Now we have a problem that the register al
On 02/08/11 13:22, Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> Michael Walle writes:
>> >
>> > Hi,
>> >
>> > > To confirm that try -fno-tree-ter.
>> >
>> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
>> > assembly code:
On 08/08/2011 10:06 AM, Richard Guenther wrote:
Like if
register unsigned char *ip;
would increase spill cost of ip compared to
unsigned char *ip;
?
Remember we're talking about a function with 11000 pseudos and 4000
allocnos (not to mention a 1500 basic blocks). You cannot really blame
On Sat, Aug 6, 2011 at 5:00 PM, Paolo Bonzini wrote:
> On 08/04/2011 01:10 PM, Andrew Haley wrote:
>> It's the sort of thing that gets done in threaded interpreters,
>> where you really need to keep a few pointers in registers and
>> the interpreter itself is a very long fun
On 08/04/2011 01:10 PM, Andrew Haley wrote:
>> It's the sort of thing that gets done in threaded interpreters,
>> where you really need to keep a few pointers in registers and
>> the interpreter itself is a very long function. gcc has always
>> done a dreadful job of register allocation in s
On 08/04/2011 12:19 PM, Richard Guenther wrote:
> On Thu, Aug 4, 2011 at 1:10 PM, Andrew Haley wrote:
>> On 08/04/2011 10:52 AM, Richard Guenther wrote:
>>> On Thu, Aug 4, 2011 at 11:50 AM, Andrew Haley wrote:
On 08/04/2011 01:19 AM, Hans-Peter Nilsson wrote:
> To make sure, it'd be
On Thu, 4 Aug 2011, Andreas Schwab wrote:
> Hans-Peter Nilsson writes:
>
> > To make sure, it'd be nice if someone could perhaps grep an
> > entire GNU/Linux-or-other distribution including the kernel for
> > uses of asm-declared *local* registers that don't directly feed
> > into asms and not bei
On Thu, Aug 4, 2011 at 1:10 PM, Andrew Haley wrote:
> On 08/04/2011 10:52 AM, Richard Guenther wrote:
>> On Thu, Aug 4, 2011 at 11:50 AM, Andrew Haley wrote:
>>> On 08/04/2011 01:19 AM, Hans-Peter Nilsson wrote:
>>>
To make sure, it'd be nice if someone could perhaps grep an
entire GNU/
On 08/04/2011 10:52 AM, Richard Guenther wrote:
> On Thu, Aug 4, 2011 at 11:50 AM, Andrew Haley wrote:
>> On 08/04/2011 01:19 AM, Hans-Peter Nilsson wrote:
>>
>>> To make sure, it'd be nice if someone could perhaps grep an
>>> entire GNU/Linux-or-other distribution including the kernel for
>>> use
On Thu, Aug 4, 2011 at 11:50 AM, Andrew Haley wrote:
> On 08/04/2011 01:19 AM, Hans-Peter Nilsson wrote:
>
>> To make sure, it'd be nice if someone could perhaps grep an
>> entire GNU/Linux-or-other distribution including the kernel for
>> uses of asm-declared *local* registers that don't directly
On 08/04/2011 01:19 AM, Hans-Peter Nilsson wrote:
> To make sure, it'd be nice if someone could perhaps grep an
> entire GNU/Linux-or-other distribution including the kernel for
> uses of asm-declared *local* registers that don't directly feed
> into asms and not being the stack-pointer? Or can w
Hans-Peter Nilsson writes:
> To make sure, it'd be nice if someone could perhaps grep an
> entire GNU/Linux-or-other distribution including the kernel for
> uses of asm-declared *local* registers that don't directly feed
> into asms and not being the stack-pointer?
One frequent candidate is the
On Wed, 3 Aug 2011, Ulrich Weigand wrote:
> Richard Guenther wrote:
> > asm ("scall" : : "asm("r0")" (10), ...)
> Maybe it would be possible to implement this while keeping the syntax
> of existing code by (re-)defining the semantics of register asm to
> basically say that:
>
> If a variable X is
On 08/03/2011 07:02 AM, Richard Guenther wrote:
> Reserved registers are a no-go (like %esp), either global or local.
Local register variables referring to anything in fixed_regs
are trivial to handle -- continue to treat them exactly as we
currently do. They won't be clobbered by random code mov
Richard Guenther wrote:
> On Wed, Aug 3, 2011 at 3:27 PM, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 3 Aug 2011, Richard Guenther wrote:
>>
Yes, that's reasonable. As I understand the docs, in code like
void foo ()
{
register int var asm ("r1") = 10;
asm (";; use r
On Wed, Aug 3, 2011 at 3:27 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 3 Aug 2011, Richard Guenther wrote:
>
>> > Yes, that's reasonable. As I understand the docs, in code like
>> >
>> > void foo ()
>> > {
>> > register int var asm ("r1") = 10;
>> > asm (";; use r1");
>> > }
>> >
>> > there is
Hi,
On Wed, 3 Aug 2011, Richard Guenther wrote:
> > Yes, that's reasonable. As I understand the docs, in code like
> >
> > void foo ()
> > {
> > register int var asm ("r1") = 10;
> > asm (";; use r1");
> > }
> >
> > there is nothing that connects var to the asm and assuming that
> > r1 holds
On Wed, Aug 3, 2011 at 11:50 AM, Georg-Johann Lay wrote:
> Ulrich Weigand wrote:
>> Richard Guenther wrote:
>>> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
Richard Guenther writes:
> I suggest to amend the documentation for local call-clobbered register
> variables to sa
Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
>>> Richard Guenther writes:
I suggest to amend the documentation for local call-clobbered register
variables to say that the only valid sequence using them is from a
non-inli
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
> > Richard Guenther writes:
> >> I suggest to amend the documentation for local call-clobbered register
> >> variables to say that the only valid sequence using them is from a
> >> non-inlinable function that conta
Richard Guenther writes:
> But then can't people use a pure assembler stub instead? Without
> inlining there isn't much benefit left from writing
>
> void f1(int arg)
> {
> register int a1 asm("r8") = 10;
> register int a2 asm("r1") = arg;
>
> asm("scall" : : "r"(a1), "r"(a2));
> }
>
> i
On Tue, Aug 2, 2011 at 6:02 PM, Richard Henderson wrote:
> On 08/02/2011 05:22 AM, Richard Guenther wrote:
>>> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4.
>>
>> It's of course only a workaround, not a real fix as nothing prevents
>> other optimizers from performing the re-
Richard Guenther schrieb:
I suggest to amend the documentation for local call-clobbered register
variables to say that the only valid sequence using them is from a
non-inlinable function that contains only direct initializations of the
register variables from constants or parameters.
Richard.
On 08/02/2011 05:22 AM, Richard Guenther wrote:
>> -fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4.
>
> It's of course only a workaround, not a real fix as nothing prevents
> other optimizers from performing the re-scheduling TER does.
>
> I suggest to amend the documentation
Richard Guenther writes:
> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> Or go one step further and deprecate local register variables alltogether
>>> (they IMHO don't make much sense, and rather the targets should provide
>>> a way to properly const
On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> Or go one step further and deprecate local register variables alltogether
>> (they IMHO don't make much sense, and rather the targets should provide
>> a way to properly constrain asm inputs and outputs).
>
>
Richard Guenther writes:
> Or go one step further and deprecate local register variables alltogether
> (they IMHO don't make much sense, and rather the targets should provide
> a way to properly constrain asm inputs and outputs).
No, local register variables are documented as working and many pr
On Tue, 2 Aug 2011, Richard Guenther wrote:
> > I'd be ok with that, FWIW; I see the problem with keeping the
> > scheduling of operations in a working order (yuck) and I don't
> > see how else to keep it working ...except perhaps make gcc flag
> > functions with register asms as non-inlinable, may
On Tue, Aug 2, 2011 at 2:53 PM, Hans-Peter Nilsson wrote:
> On Tue, 2 Aug 2011, Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> > Michael Walle writes:
>> > >
>> > > Hi,
>> > >
>> > > > To confirm that try -fno-tree-ter.
>> > >
>> > > "lm32-gcc -O1 -fn
On Tue, 2 Aug 2011, Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
> > Michael Walle writes:
> > >
> > > Hi,
> > >
> > > > To confirm that try -fno-tree-ter.
> > >
> > > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> > > assem
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
>> Michael Walle writes:
>> >
>> > Hi,
>> >
>> > > To confirm that try -fno-tree-ter.
>> >
>> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
>> > assembly code:
>> >
>> > f2:
>>
On Tue, Aug 2, 2011 at 2:06 PM, Mikael Pettersson wrote:
> Michael Walle writes:
> >
> > Hi,
> >
> > > To confirm that try -fno-tree-ter.
> >
> > "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> > assembly code:
> >
> > f2:
> > addi sp, sp, -4
> >
Michael Walle writes:
>
> Hi,
>
> > To confirm that try -fno-tree-ter.
>
> "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> assembly code:
>
> f2:
> addi sp, sp, -4
> sw (sp+4), ra
> addi r2, r0, 10
> calli__ashrsi3
Hi,
> To confirm that try -fno-tree-ter.
"lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
assembly code:
f2:
addi sp, sp, -4
sw (sp+4), ra
addi r2, r0, 10
calli__ashrsi3
addi r8, r0, 10
scall
On Tue, Aug 2, 2011 at 12:01 PM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
>>> Hans-Peter Nilsson writes:
>>> > On Mon, 1 Aug 2011, Richard Henderson wrote:
>>> >
>>> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
>>> > >
Richard Guenther wrote:
> On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
>> Hans-Peter Nilsson writes:
>> > On Mon, 1 Aug 2011, Richard Henderson wrote:
>> >
>> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
>> > > > 1) function inlining
>> > > > 2) deferred argument evaluation
On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson wrote:
> Hans-Peter Nilsson writes:
> > On Mon, 1 Aug 2011, Richard Henderson wrote:
> >
> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
> > > > 1) function inlining
> > > > 2) deferred argument evaluation
> > > > 3) because our target
Hans-Peter Nilsson writes:
> On Mon, 1 Aug 2011, Richard Henderson wrote:
>
> > On 08/01/2011 01:30 PM, Michael Walle wrote:
> > > 1) function inlining
> > > 2) deferred argument evaluation
> > > 3) because our target has no barrel shifter, (arg >> 10) is emitted as a
> > > function call
Michael Walle wrote:
> Hi,
>
> That was quick :)
>
>> Your asm has no output operands and no side effects, with more
>> aggressive optimization the whole ask would disappear.
> Sorry, that was just a small test file, the original code has output operands.
>
> The new test code:
> static int inl
On Mon, 1 Aug 2011, Richard Henderson wrote:
> On 08/01/2011 01:30 PM, Michael Walle wrote:
> > 1) function inlining
> > 2) deferred argument evaluation
> > 3) because our target has no barrel shifter, (arg >> 10) is emitted as a
> > function call to libgcc's __ashrsi3 (_in place_!)
> > 4) BAM
On Mon, 1 Aug 2011, Georg-Johann Lay wrote:
> Michael Walle schrieb:
> > Hi list,
> >
> > consider the following test code:
> > static void inline f1(int arg)
> > {
> >register int a1 asm("r8") = 10;
> >register int a2 asm("r1") = arg;
> >
> >asm("scall" : : "r"(a1), "r"(a2));
> > }
On 08/01/2011 01:30 PM, Michael Walle wrote:
> 1) function inlining
> 2) deferred argument evaluation
> 3) because our target has no barrel shifter, (arg >> 10) is emitted as a
> function call to libgcc's __ashrsi3 (_in place_!)
> 4) BAM! dead code elimination optimizes r8 assignment away becau
Hi,
That was quick :)
> Your asm has no output operands and no side effects, with more
> aggressive optimization the whole ask would disappear.
Sorry, that was just a small test file, the original code has output operands.
The new test code:
static int inline f1(int arg)
{
register int ret
Michael Walle schrieb:
Hi list,
consider the following test code:
static void inline f1(int arg)
{
register int a1 asm("r8") = 10;
register int a2 asm("r1") = arg;
asm("scall" : : "r"(a1), "r"(a2));
}
void f2(int arg)
{
f1(arg >> 10);
}
If you compile this code with 'lm32-g
Hi list,
consider the following test code:
static void inline f1(int arg)
{
register int a1 asm("r8") = 10;
register int a2 asm("r1") = arg;
asm("scall" : : "r"(a1), "r"(a2));
}
void f2(int arg)
{
f1(arg >> 10);
}
If you compile this code with 'lm32-gcc -O1 -S -c test.c' (se
47 matches
Mail list logo
