2013/6/4 Jeff Law :
> On 06/03/2013 08:23 AM, Kai Tietz wrote:
>>
>>
>> Btw there is one optimization in this context which might be something
>> worth here too.
>> -X -> X for 1-bit typed X (signed doesn't matter here).
>
> I've had a hell of a time trying to trigger a case where this isn't alread
> Eventually we should force all BOOLEAN_TYPEs to have precision 1 but
> as Kai remembers Ada uses alternate values for verification (true, false,
> NaT or so). Eric may be able to explain.
Correct, see: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01214.html
A boolean type isn't a modular type o
On Tue, Jun 4, 2013 at 9:20 PM, Jeff Law wrote:
> On 06/03/2013 08:23 AM, Kai Tietz wrote:
>>
>>
>> Btw there is one optimization in this context which might be something
>> worth here too.
>> -X -> X for 1-bit typed X (signed doesn't matter here).
>
> I've had a hell of a time trying to trigger a
1) GCC uses the all-fields instruction instead of the one-field
form unless you use -mmfcrf (or -mcpu=power4, etc.), although
the one-field mfcr works fine on all CPUs and is never slower
(I'm not talking about mfocrf; just the plain mfcr instruction);
Ugh, need more coffee, forget about this on
We cannot avoid an mfcr then, either. It would be one machine
instruction shorter though (but can be more expensive to execute,
on some CPUs).
That you get two MFCRs on 64-bit is a target bug.
Not true there. If you look at the 64bit output you will see you are
using the one cr mfcr version i
On Tue, Jun 4, 2013 at 6:42 PM, Segher Boessenkool
wrote:
>> However, in looking at it, if we rewrite the code to have come from
>> comparisons:
>
>
>
>
>
>> _Bool bfoo_cmp (long w, long x, long y, long z)
>> {
>> _Bool a = (w < x);
>> _Bool b = (y < z);
>> _Bool r = ~a & b;
>> return r;
However, in looking at it, if we rewrite the code to have come from
comparisons:
_Bool bfoo_cmp (long w, long x, long y, long z)
{
_Bool a = (w < x);
_Bool b = (y < z);
_Bool r = ~a & b;
return r;
}
We get:
.L.bfoo_cmp:
cmpd 6,3,4
cmpd 7,5,6
mfcr 3,2
On 06/03/2013 08:23 AM, Kai Tietz wrote:
Btw there is one optimization in this context which might be something
worth here too.
-X -> X for 1-bit typed X (signed doesn't matter here).
I've had a hell of a time trying to trigger a case where this isn't
already handled. Samples welcome.
2013/6/4 Jeff Law :
> On 06/04/2013 04:45 AM, Richard Biener wrote:
>>>
>>>
>>> Yes. Booleans are integral types with a single bit of precision, right?
>>> So
>>> this check should allow boolean types. What am I missing?
>>
>>
>> We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one
>> (
On 06/04/2013 04:45 AM, Richard Biener wrote:
Yes. Booleans are integral types with a single bit of precision, right? So
this check should allow boolean types. What am I missing?
We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one
(but still are two-valued, and we assume those va
On Mon, Jun 3, 2013 at 8:34 PM, Jeff Law wrote:
> On 06/03/2013 12:32 PM, Kai Tietz wrote:
>>
>> 2013/6/3 Jeff Law :
>>>
>>> On 06/03/2013 11:00 AM, Richard Henderson wrote:
On 06/03/2013 09:37 AM, Kai Tietz wrote:
>
>
> foo:
> .seh_endprologue
>
On Mon, Jun 3, 2013 at 6:05 PM, Jeff Law wrote:
> On 06/03/2013 02:24 AM, Richard Biener wrote:
>>
>> On Fri, May 31, 2013 at 10:18 PM, Jeff Law wrote:
>>>
>>>
>>> This is an implementation to fix a missed optimization pointed out to me
>>> by
>>> Kai.
>>>
>>> In all these examples, assume a & b
On Mon, Jun 03, 2013 at 10:00:19AM -0700, Richard Henderson wrote:
> On 06/03/2013 09:37 AM, Kai Tietz wrote:
> > foo:
> > .seh_endprologue
> > cmpb%cl, %dl
> > seta%al
> > ret
> > .seh_endproc
> > .p2align 4,,15
> > .globl boo
> >
On 06/03/2013 12:32 PM, Kai Tietz wrote:
2013/6/3 Jeff Law :
On 06/03/2013 11:00 AM, Richard Henderson wrote:
On 06/03/2013 09:37 AM, Kai Tietz wrote:
foo:
.seh_endprologue
cmpb%cl, %dl
seta%al
ret
.seh_endproc
.p2align 4,,1
2013/6/3 Jeff Law :
> On 06/03/2013 11:00 AM, Richard Henderson wrote:
>>
>> On 06/03/2013 09:37 AM, Kai Tietz wrote:
>>>
>>> foo:
>>> .seh_endprologue
>>> cmpb%cl, %dl
>>> seta%al
>>> ret
>>> .seh_endproc
>>> .p2align 4,,15
>>>
On 06/03/2013 09:37 AM, Kai Tietz wrote:
> foo:
> .seh_endprologue
> cmpb%cl, %dl
> seta%al
> ret
> .seh_endproc
> .p2align 4,,15
> .globl boo
> .defboo;.scl2; .type 32; .endef
> .seh_proc
On 06/03/2013 11:00 AM, Richard Henderson wrote:
On 06/03/2013 09:37 AM, Kai Tietz wrote:
foo:
.seh_endprologue
cmpb%cl, %dl
seta%al
ret
.seh_endproc
.p2align 4,,15
.globl boo
.defboo;.scl2; .type
2013/6/3 Jeff Law :
> The counter to that argument of leaving it to the backend to recover the
> and-not for is that the backend doesn't typically see these as single bit
> operations which makes turning the relational back into an and-not sequence
> considerably more difficult.
>
> Do we consider
On 06/03/2013 02:24 AM, Richard Biener wrote:
On Fri, May 31, 2013 at 10:18 PM, Jeff Law wrote:
This is an implementation to fix a missed optimization pointed out to me by
Kai.
In all these examples, assume a & b are single bit types.
~a && b --> a < b
For a signed 1-bit type you'll have v
Hmm, it isn't necessary to restrict this optimization AFAICS. We have
just two cases.
(~X & Y) -> X < Y
(X & ~Y) -> Y < X
(~X | Y) -> X <= Y
(X | ~Y) -> Y <= X
is true for unsigned 1-bit types.
For signed 1-bit types we need to invert logic here as following:
(~X & Y) -> X > Y
(X & ~Y) -> Y >
On Fri, May 31, 2013 at 10:18 PM, Jeff Law wrote:
>
> This is an implementation to fix a missed optimization pointed out to me by
> Kai.
>
> In all these examples, assume a & b are single bit types.
>
> ~a && b --> a < b
For a signed 1-bit type you'll have values -1, 0 and clearly
0 < -1
is f
This is an implementation to fix a missed optimization pointed out to me
by Kai.
In all these examples, assume a & b are single bit types.
~a && b --> a < b
a && ~b --> b < a
~a || b --> a <= b
a && ~b --> b <= a
This happens with some regularity in GCC itself, though it's not as
pervasive
22 matches
Mail list logo
