On 22/04/15 10:39 AM, Georg-Johann Lay wrote:
Attached is a C test program which produces fine results with
$ avr-gcc -S -O2 -mmcu=atmega8
Also attached is a respective patch against the trunk avr backend that
indicates the transition from clobbers to hard-regs-by-constraint.
I don't
Am 04/20/2015 um 10:11 PM schrieb Vladimir Makarov:
On 17/04/15 05:58 AM, Georg-Johann Lay wrote:
I allowed me to CC Vladimir; maybe he can propose how the backend can
describe an efficient, constraint-based solution. The problem is about
expanders producing insns with non-fixed hard-regs as
On Tue, Apr 21, 2015 at 11:55:33PM -0400, Vladimir Makarov wrote:
The combiner can add or remove clobbers of scratches whenever needed,
but it cannot do that for clobbers of pseudos.
Yes, I think there are some pitfalls with scratches in other passes.
Probably. But this one is documented
On 22/04/15 08:27, Segher Boessenkool wrote:
On Tue, Apr 21, 2015 at 11:55:33PM -0400, Vladimir Makarov wrote:
The combiner can add or remove clobbers of scratches whenever needed,
but it cannot do that for clobbers of pseudos.
Yes, I think there are some pitfalls with scratches in other
On Tue, Apr 21, 2015 at 12:27:40AM +0200, Steven Bosscher wrote:
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
I might be wrong but I think you have a bloated code because you use
scratches. I already told several times that usage of scratch is always a
bad idea. It was a bad
On 21/04/15 02:04 AM, Segher Boessenkool wrote:
On Tue, Apr 21, 2015 at 12:27:40AM +0200, Steven Bosscher wrote:
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
I might be wrong but I think you have a bloated code because you use
scratches. I already told several times that usage
On 17/04/15 05:58 AM, Georg-Johann Lay wrote:
I allowed me to CC Vladimir; maybe he can propose how the backend can
describe an efficient, constraint-based solution. The problem is
about expanders producing insns with non-fixed hard-regs as in/out
operands or clobbers. This includes move
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
I might be wrong but I think you have a bloated code because you use
scratches. I already told several times that usage of scratch is always a
bad idea. It was a bad idea for an old RA and is still a bad idea for IRA.
The usage of
On 20/04/15 06:27 PM, Steven Bosscher wrote:
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
I might be wrong but I think you have a bloated code because you use
scratches. I already told several times that usage of scratch is always a
bad idea. It was a bad idea for an old RA and
I allowed me to CC Vladimir; maybe he can propose how the backend can describe
an efficient, constraint-based solution. The problem is about expanders
producing insns with non-fixed hard-regs as in/out operands or clobbers. This
includes move insn from non-generic address spaces which require
Am 10/27/2014 08:43 PM, schrieb Jeff Law:
On 10/27/14 13:33, Georg-Johann Lay wrote:
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit
tedious,
but well...
In one
On Tue, Oct 28, 2014 at 01:06:38PM +0100, Georg-Johann Lay wrote:
The C test case is
__attribute__((noinline,noclone))
unsigned bug_mulhi_highpart (unsigned x)
{
register unsigned reg26 asm (26) = 10;
a = x / 10;
__asm volatile (; %0 : +r (reg26));
return reg26;
}
On 10/28/14 06:40, Jakub Jelinek wrote:
I'd say if on the target reg26 or reg27 is used or clobbered by
multiplication, then it is a user error to use it this way, the register
then isn't suitable for the local hard register usage.
Right.
And this situation is a great example of why
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit tedious,
but well...
In one case expmed generated different code, though: divmodhi instead of
mulhi_highpart for
On 10/27/14 13:33, Georg-Johann Lay wrote:
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit
tedious,
but well...
In one case expmed generated different code,
Investigating PR63633 turned out that the middle-end calls insn expanders with
hard registers, namely mulsi3 from avr back-end:
(define_expand mulsi3
[(parallel [(set (match_operand:SI 0 register_operand )
(mult:SI (match_operand:SI 1 register_operand )
On 10/24/14 08:03, Georg-Johann Lay wrote:
Investigating PR63633 turned out that the middle-end calls insn
expanders with hard registers, namely mulsi3 from avr back-end:
(define_expand mulsi3
[(parallel [(set (match_operand:SI 0 register_operand )
(mult:SI
On Fri, Oct 24, 2014 at 10:23:22AM -0600, Jeff Law wrote:
On 10/24/14 08:03, Georg-Johann Lay wrote:
Investigating PR63633 turned out that the middle-end calls insn
expanders with hard registers, namely mulsi3 from avr back-end:
(define_expand mulsi3
[(parallel [(set (match_operand:SI 0
On 10/24/14 10:29, Jakub Jelinek wrote:
But I'd say, if you can't handle hard regs in the operands (either general,
or some specific ones), you should
force the hard regs into pseudos (all hard regs, or just the problematic
ones) in the expander.
So in this case, check if they overlap with
Jeff Law schrieb:
On 10/24/14 10:29, Jakub Jelinek wrote:
But I'd say, if you can't handle hard regs in the operands (either
general,
or some specific ones), you should
force the hard regs into pseudos (all hard regs, or just the problematic
ones) in the expander.
So in this case, check if
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit tedious,
but well...
In one case expmed generated different code, though: divmodhi instead of
mulhi_highpart for HI division by const_int. Cheating with costs
On 10/24/14 12:19, Georg-Johann Lay wrote:
1) May it happen that a value lives in a hard-reg across the expander?
The expander has no means to detect that situation and interfere, e.g.
hard-reg = source_value // middle-end
expand-code // back-end
sink_value = hard-reg //
22 matches
Mail list logo
