On Aug 1, 2012, at 16:04 , Ulrich Weigand wrote:
> I've been wondering about mode_dependent_address_p myself. It currently
> appears to cover two quite separate questions:
>
> - If I have a valid address, will it remain valid if I change its mode to
> something else?
>
> - If I have a valid ad
Olivier Hainque wrote:
> I had made a proposal to help the rs6000_mode_dependent_address
> issue, http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
>
> Seems to me that the general idea is still valid:
>
> << a number of places in the compiler use the
>mode_dependent_address_p predica
On Aug 1, 2012, at 13:18 , Alan Modra wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
> I like the idea.
:-)
> It is worth pursuing for code improvement we'll see
> even if we avoid the "o" constraint everywhere. For example,
> long long llo (long long *x) { return x
On Wed, Aug 01, 2012 at 10:26:50AM +0200, Olivier Hainque wrote:
> I had made a proposal to help the rs6000_mode_dependent_address
> issue, http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
>
> Seems to me that the general idea is still valid:
>
> << a number of places in the compiler use
On Jul 17, 2012, at 17:34 , Alan Modra wrote:
> The ICE is
>
> combine.c:5318:1: error: insn does not satisfy its constraints:
> (insn 4211 1484 1493 140 (set (mem/c:DI (plus:SI (reg/f:SI 19 19 [2736])
>(const_int 32760 [0x7ff8])) [3 __gcov0.subst+816 S8 A64])
>(reg:DI 6 6
Alan Modra wrote:
> However, the "o" constraint rejects any offset >= 0x7ff4 due to
> rs6000_mode_dependent_address. This particular problem has been known
> for a long time, but that's not the only problem with "o" (and also
> the rs6000 "Y" constraint, a variant of "o"). A more subtle
> requir
This email is a result of delving into
https://bugzilla.redhat.com/show_bug.cgi?id=837630 an ICE when
building powerpc-linux gcc 4.7.1 with -fprofile-generate. I'm asking
for corrections/advice/guidance from anyone with a good working
knowledge of reload!
The ICE is
combine.c:5318:1: error: insn
Quoting Jean Christophe Beyler :
I have an expand_move that rejects anything not accepted, a check_move
that makes sure everything is ok and the constraints that go with (my
'R' constraint).
The instruction generated during greg should normally be refused.
From what you've said, it seems that I
> Not that I can think of. Did you provide all of the secondary reload
> stuff that you need? Probably not.
Probably not, I've been working at cleaning up what was done before.
What exactly is needed to be done to define the secondary reload stuff
?
> You'll do much better by rejecting these ad
On 09/16/2009 03:00 PM, Jean Christophe Beyler wrote:
Sorry to bring this back to the conversation. Is there any reason why
this would not work with floating-point constraints ?
Not that I can think of. Did you provide all of the secondary reload
stuff that you need? Probably not.
(define_m
Sorry to bring this back to the conversation. Is there any reason why
this would not work with floating-point constraints ?
My "R" constraint is defined as:
(define_memory_constraint "R"
"R is for memory references which take 1 word for the instruction"
(and (match_code "mem")
(match_t
On 09/14/2009 12:18 PM, Jean Christophe Beyler wrote:
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R")
(match_operand:DI 1 "general_operand" "r,i,R,r"))]
Where R checks if the operand is a memory operand and if the offset is correct.
Did you use define_memory_const
Dear all,
I was working on simplifying the movdi in my port and I had put :
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,o")
(match_operand:DI 1 "general_operand" "r,i,o,r"))]
However, due to constraints on the offset that is allowed, I:
- Added the check of the offse
Hi, I already submitted some patches for the avr backend and have still
a bunch of ideas for implrovements.
However, I am still unsure about insn constraints and what they must
look like to work in any situation, and I want to learn more about that
subject before commnuity tars and feathers me
14 matches
Mail list logo
