On Tue, Jul 11, 2017 at 11:14:20AM +0200, Georg-Johann Lay wrote:
> On 10.07.2017 23:40, Segher Boessenkool wrote:
> >On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
> >>Any ideas for a sane approach?
> >
> >You could change insn_rtx_cost to actually calculate the cost of the
> >i
On 07/10/2017 05:10 PM, Georg-Johann Lay wrote:
> (set (zero_extract:QI (reg/i:QI 24 r24)
> (const_int 1 [0x1])
> (const_int 6 [0x6]))
> (lshiftrt:QI (reg:QI 52)
> (const_int 6 [0x6])))
> The problem is that the backend only sees
>
> avr_rtx_costs[bset:combine(266)]=tr
On 10.07.2017 23:40, Segher Boessenkool wrote:
On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
Any ideas for a sane approach?
You could change insn_rtx_cost to actually calculate the cost of the
insn, not just set_src_cost of a single set. This will need checking
on a great
On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
> Any ideas for a sane approach?
You could change insn_rtx_cost to actually calculate the cost of the
insn, not just set_src_cost of a single set. This will need checking
on a great many targets, not in the least because most targe
Hi, I'd need some help with the following optimization issue:
avr backend supports insns for bit insertion, and insn combiner tries to
use them:
unsigned char bset (unsigned char a, unsigned char n)
{
return (a & ~0x40) | (n & 0x40);
}
Trying 7 -> 14:
Successfully matched
"extractua\t %2, %3, %1, %0 %!"
>>> )
>>>
>>> and
>>>
>>> (define_insn "cmprr_hi_"
>>> [(set (match_operand:BI 0 "register_operand" "=c")
>>> (any_cond_rr:BI (match_operand:HI
"immediate_operand" "U06")))]
> ""
> "extractua\t %2, %3, %1, %0 %!"
> )
>
> and
>
> (define_insn "cmprr_hi_"
> [(set (match_operand:BI 0 "register_operand" "=c")
> (any_cond_rr:BI (match_operand:H
)
and
(define_insn "cmprr_hi_"
[(set (match_operand:BI 0 "register_operand" "=c")
(any_cond_rr:BI (match_operand:HI 1 "register_operand" "d")
(match_operand:HI 2 "register_operand" "d")))]
""
On 2/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> My question is that, IMO the test is checking overflow behaviour. Is
> it right to have such a test ?
Would you care to prepare a patch that moved it under gcc.dg, adding a {
dg-options "-O2 -fno-strict-overflow" } marker (or maybe "-O2
-fn
My question is that, IMO the test is checking overflow behaviour. Is
it right to have such a test ?
Would you care to prepare a patch that moved it under gcc.dg, adding a {
dg-options "-O2 -fno-strict-overflow" } marker (or maybe "-O2
-fno-wrapv")? But your optimization should also be condi
Hello all,
I added a small optimization which does the following . It converts
a = a + 1
if ( a > 0 )
to
if ( a > -1)
a is a signed int.
However this is causing 920612-1.c to fail, which is reproduced below
for convenience.
f(j)int j;{return++j>0;}
main(){ if(f((~0U)>>1)) abort(); exit(0); }
T
[EMAIL PROTECTED] wrote:
I guess the combiner generates something like
a trucation pattern when special constant are detected.
The combiner also takse a similiar action in pattern
See the section of the documentation that talks about instruction
canonicalization.
http://gcc.gnu.org
You are cool, now I found a
(set (reg:CC_Z 33 cc)
(compare:CC_Z (zero_extend:SI (subreg:QI (reg/v:SI 166 [ a ]) 0))
(const_int 0 [0x0])))
It's what I'm looking for.
Thank you so much.
But I found they fails to match
if(foo & 0xff) and if(foo & 0x)
These get simplified to foo.
Look at the debugging dump before the combine pass to see what you
need to match.
It doesn't work that way. What you get from there are only the insn numbers.
Then you run cc1 (or whatever lan
uot; of
the combination.
But what I wanna know is why the "output"
of case (2) acts against my expection,
and the debugging dump tells nothing about that.
Because things also happens in
3.) if(foo & 0x)
I guess the combiner generates something like
a trucation pattern when s
[EMAIL PROTECTED] writes:
> Does the instruction combiner regards (foo & 0xff) as a special case?
>
> I have two patterns which I expect to match all the
>
> if(foo & $(constant)) patterns. They are
>
> [(set (reg:CC_Z CC_REGNUM)
> (comp
Does the instruction combiner regards (foo & 0xff) as a special case?
I have two patterns which I expect to match all the
if(foo & $(constant)) patterns. They are
[(set (reg:CC_Z CC_REGNUM)
(compare:CC_Z
(and:SI (match_operand:SI 0 "reg
17 matches
Mail list logo
