Ian Lance Taylor wrote:
> Georg-Johann Lay:
>>
>> What about that predicate?
>>
>> (define_predicate "low_io_mem"
>>(and (match_code "mem")
>> (match_test "low_io_address_operand (XEXP (op, 0))")))
>>
>> Guess it operates the same because the drag-volatile-over-volatile
>> happens not i
On Sun, 4 Dec 2011, Richard Guenther wrote:
> On Sat, Dec 3, 2011 at 7:56 PM, Richard Henderson wrote:
> > On 12/03/2011 06:30 AM, Richard Guenther wrote:
> >> Not if you look at the respective gimple level dependency routines
> >> in tree-ssa-alias.c, OTOH tree-data-ref.c simply refuses to handl
On Sat, Dec 3, 2011 at 7:56 PM, Richard Henderson wrote:
> On 12/03/2011 06:30 AM, Richard Guenther wrote:
>> Not if you look at the respective gimple level dependency routines
>> in tree-ssa-alias.c, OTOH tree-data-ref.c simply refuses to handle
>> volatile references at all.
>
> That's something
On 12/03/2011 06:30 AM, Richard Guenther wrote:
> Not if you look at the respective gimple level dependency routines
> in tree-ssa-alias.c, OTOH tree-data-ref.c simply refuses to handle
> volatile references at all.
That's something we'd better fix, then, regardless of whether
some pass currently
On Sat, Dec 3, 2011 at 12:42 AM, Richard Henderson wrote:
> On 12/02/2011 06:35 AM, Richard Guenther wrote:
>> I see. As we do not explicitely model this dependency we probably
>> get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
>> passes do.
>
> What are you talking about? Of cou
On 12/02/2011 06:35 AM, Richard Guenther wrote:
> I see. As we do not explicitely model this dependency we probably
> get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
> passes do.
What are you talking about? Of course we do.
> int
> read_dependence (const_rtx mem, const_rtx x)
>
Paul Koning writes:
>> I see. As we do not explicitely model this dependency we probably get lucky
>> by the if (gimple_has_volatile_ops ()) bail-out; most passes do.
>
> That sounds scary, if I understood you correctly. It sounds like GCC
> conforms to the standard only by accident rather th
>
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: Friday, December 02, 2011 9:35 AM
> To: Andrew Haley
> Cc: gcc@gcc.gnu.org
> Subject: Re: volatile correctness: combine vs. target.md
>
On Fri, Dec 2, 2011 at 9:26 AM, Dave Korn wrote:
> On 01/12/2011 21:40, Georg-Johann Lay wrote:
>
>> It's not unusual because:
>>
>> * It's not unusual to write down SFRs as violatile memory like
>> (*((volatile unsigned int*) 0x1234)) or as a cast to a composite
>> that reflects the SFRs bit(
On 01/12/2011 21:40, Georg-Johann Lay wrote:
> It's not unusual because:
>
> * It's not unusual to write down SFRs as violatile memory like
> (*((volatile unsigned int*) 0x1234)) or as a cast to a composite
> that reflects the SFRs bit(field)s.
>
> * It's not unusual that microcontrollers ca
On 02/12/2011 13:59, Andrew Haley wrote:
On Fri, Dec 2, 2011 at 5:46 AM, wrote:
...
It's never correct to exchange volatile accesses.
That's not true. volatile accesses to different memory locations
have no special dependence. If it happens that GCC doesn't
do this kind of things then thi
On Fri, Dec 2, 2011 at 1:59 PM, Andrew Haley wrote:
> On Fri, Dec 2, 2011 at 5:46 AM, wrote:
>> >
>> > ...
> >> It's never correct to exchange volatile accesses.
>>> > >
>>> > >That's not true. volatile accesses to different memory locations
>>> > >have no special dependence. If it happens
Richard Guenther wrote:
> On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote:
>> Ian Lance Taylor wrote:
>>
>>> Georg-Johann Lay writes:
>>>
If general_operand can be perceived as
(define_predicate "general_operand"
(ior (match_operand 0 "memory_operand")
(match
On Fri, Dec 2, 2011 at 5:46 AM, wrote:
> >
> > ...
>>> > >> It's never correct to exchange volatile accesses.
>> > >
>> > >That's not true. volatile accesses to different memory locations
>> > >have no special dependence. If it happens that GCC doesn't
>> > >do this kind of things then this is o
On Fri, Dec 2, 2011 at 1:14 PM, Peter Bigot wrote:
> On Fri, Dec 2, 2011 at 5:46 AM, wrote:
>>
>> ...
>> >> It's never correct to exchange volatile accesses.
>> >
>> >That's not true. volatile accesses to different memory locations
>> >have no special dependence. If it happens that GCC doesn't
On Fri, Dec 2, 2011 at 5:46 AM, wrote:
>
> ...
> >> It's never correct to exchange volatile accesses.
> >
> >That's not true. volatile accesses to different memory locations
> >have no special dependence. If it happens that GCC doesn't
> >do this kind of things then this is only because most pas
...
>> It's never correct to exchange volatile accesses.
>
>That's not true. volatile accesses to different memory locations
>have no special dependence. If it happens that GCC doesn't
>do this kind of things then this is only because most passes
>don't thouch volatile stmts at all (thus the repo
On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote:
> Ian Lance Taylor wrote:
>
>> Georg-Johann Lay writes:
>>
>>> If general_operand can be perceived as
>>>
>>> (define_predicate "general_operand"
>>> (ior (match_operand 0 "memory_operand")
>>> (match_operand 0 "register_operand")
>>>
Georg-Johann Lay writes:
> Ian Lance Taylor wrote:
>
>> It's a case that will never ordinarily arise. It only
>> arises for you because you are specifically trying to combine a volatile
>> MEM. I don't know if it makes sense for the general purpose combine to
>> try to handle such an unusual sp
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
If general_operand can be perceived as
(define_predicate "general_operand"
(ior (match_operand 0 "memory_operand")
(match_operand 0 "register_operand")
(match_operand 0 "immediate_operand")))
how can low_io_mem ever match?
Oh
Georg-Johann Lay writes:
> If general_operand can be perceived as
>
> (define_predicate "general_operand"
>(ior (match_operand 0 "memory_operand")
> (match_operand 0 "register_operand")
> (match_operand 0 "immediate_operand")))
>
> how can low_io_mem ever match?
Oh, I see, I
Ian Lance Taylor wrote:
Georg-Johann Lay writes:
Is insn combine allowed to match the insn because from combine's
perspective just a CONST_INT (i.e. low_io_address_operand) is moved
across the access of UDR0?
Yes.
Or is this a bug in insn combine?
No.
If combine is right -- and thus the
Georg-Johann Lay writes:
> Is insn combine allowed to match the insn because from combine's
> perspective just a CONST_INT (i.e. low_io_address_operand) is moved
> across the access of UDR0?
Yes.
> Or is this a bug in insn combine?
No.
> If combine is right -- and thus the pattern is wrong --
Hi, I have a question concerning the following C code
typedef unsigned char uint8_t;
#define SEARCHING (-2)
#define UCSR0A (*(volatile uint8_t *)((0x0B) + 0x20))
#define UDR0 (*(volatile uint8_t *)((0x0C) + 0x20))
void __vector_18(void)
{
unsigned char status = UCSR0A;
unsigned char data
24 matches
Mail list logo
