> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Joseph S. Myers
>
> I'm not clear if you're proposing such a patch for review, but note:
Yep but not yet for inclusion as I'm waiting to see if this would suit the use
case of avr people.
>
> (a) you mean DEF_EXT_LIB_B
>>> On 23.10.14 at 15:42, wrote:
> On Wed, Oct 22, 2014 at 04:28:52PM +0100, Jan Beulich wrote:
>> I noticed the issue with 4.9.1 (in that x86 Linux'es
>> this_cpu_read_stable() no longer does what the comment preceding
>> its definition promises), and the example below demonstrates this in
>> a s
On Fri, Oct 24, 2014 at 10:01:52AM +0100, Jan Beulich wrote:
> > This changed because of my http://gcc.gnu.org/PR60663 fix.
> > In your testcase the inline asm doesn't have more than one output
> > (which IMNSHO is very much desirable not to CSE), and doesn't have explicit
> > clobbers either, but
>>> On 24.10.14 at 11:11, wrote:
> On Fri, Oct 24, 2014 at 10:01:52AM +0100, Jan Beulich wrote:
>> > This changed because of my http://gcc.gnu.org/PR60663 fix.
>> > In your testcase the inline asm doesn't have more than one output
>> > (which IMNSHO is very much desirable not to CSE), and doesn't
I have some plans to "clean up" the machine_mode handling and perhaps
make it hierarchical, so that functions that can only handle scalar
integer modes (say) will be able to take a scalar_int_mode rather than
a machine_mode as argument. The first step would be to do a blanket
removal of the (in C+
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 Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
> ( tl;dr: How do I handle intrinsic or builtin functions where there
> are restrictions on the arguments which can't be represented in a C
> function prototype? Do other ports have this problem, how do they
> solve it? Language extens
On 24/10/14 15:44, Segher Boessenkool wrote:
On Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
( tl;dr: How do I handle intrinsic or builtin functions where there
are restrictions on the arguments which can't be represented in a C
function prototype? Do other ports have this proble
On Fri, Oct 24, 2014 at 8:11 AM, Tejas Belagod wrote:
> On 24/10/14 15:44, Segher Boessenkool wrote:
>>
>> On Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
>>>
>>> ( tl;dr: How do I handle intrinsic or builtin functions where there
>>> are restrictions on the arguments which can't b
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 (match_op
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_o
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 those
On 24 October 2014 17:05, Andrew Pinski wrote:
> On Fri, Oct 24, 2014 at 8:11 AM, Tejas Belagod wrote:
>> The diagnostic issued points to the line in arm_neon.h, but we expect this
>> to point to the line in cr.c. I suspect we need something closer to the
>> front-end?
>
>
> You need to change a
On Fri, Oct 24, 2014 at 06:25:29PM +0100, Charles Baylis wrote:
> On 24 October 2014 17:05, Andrew Pinski wrote:
> > On Fri, Oct 24, 2014 at 8:11 AM, Tejas Belagod
> > wrote:
>
> >> The diagnostic issued points to the line in arm_neon.h, but we expect this
> >> to point to the line in cr.c. I s
On Fri, Oct 24, 2014 at 06:25:29PM +0100, Charles Baylis wrote:
> On 24 October 2014 17:05, Andrew Pinski wrote:
> > On Fri, Oct 24, 2014 at 8:11 AM, Tejas Belagod
> > wrote:
>
> >> The diagnostic issued points to the line in arm_neon.h, but we expect this
> >> to point to the line in cr.c. I s
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 th
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 c
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 // middle-en
> Hi,
>
> I find that the -mlong-calls option is not there for AARCH64. So can this
> port
> generate long calls?
> Any plan on this option? I would like to have a try on this if it's
> missing :-)
> Thanks.
Any comments?
On Fri, Oct 24, 2014 at 8:35 PM, Yangfei (Felix) wrote:
>> Hi,
>>
>> I find that the -mlong-calls option is not there for AARCH64. So can
>> this port
>> generate long calls?
>> Any plan on this option? I would like to have a try on this if it's
>> missing :-)
>> Thanks.
>
>
> Any co
20 matches
Mail list logo
