Kenneth Zadeck writes:
> On 10/19/2013 10:18 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
> + // We optimize x < y, where y is 64 or fewer bits.
> + // We have to be careful to not allow comparison t
On 10/19/2013 10:18 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like
On Oct 19, 2013, at 7:18 AM, Richard Sandiford
wrote:
> So I think Mike's original patch was right and that this extra
> "y.len == 1" check is redundant.
So, gcc's optimizer agrees with your view, it is redundant. :-)
I checked this in:
Index: wide-int.h
==
On Oct 19, 2013, at 5:20 AM, "Bernhard Reutner-Fischer"
wrote:
>> WIDE?
>
> s/positve/positive/g
Thanks. Here is what I put in:
Index: wide-int.h
===
--- wide-int.h (revision 203835)
+++ wide-int.h (working copy)
@@ -185,7 +185
Kenneth Zadeck writes:
> On 10/19/2013 05:01 AM, Richard Sandiford wrote:
>> Mike Stump writes:
>>> + // We optimize x < y, where y is 64 or fewer bits.
>>> + // We have to be careful to not allow comparison to a large positive
>>> + // unsigned value like 0x8000, those would be en
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like 0x8000, those would be encoded
+ // with a y.len == 2.
+ if (
On 18 October 2013 22:55:39 Jakub Jelinek wrote:
On Fri, Oct 18, 2013 at 01:52:54PM -0700, Mike Stump wrote:
> On Oct 18, 2013, at 6:11 AM, Kenneth Zadeck wrote:
> >>> Does this look ok? Kenny, can you double check the cases, think I
have them right, but? a double check would be good.
> >>
Mike Stump writes:
> + // We optimize x < y, where y is 64 or fewer bits.
> + // We have to be careful to not allow comparison to a large positive
> + // unsigned value like 0x8000, those would be encoded
> + // with a y.len == 2.
> + if (y.precision <= HOST_BITS_PER_WIDE_INT
> +
On Fri, Oct 18, 2013 at 01:52:54PM -0700, Mike Stump wrote:
> On Oct 18, 2013, at 6:11 AM, Kenneth Zadeck wrote:
> >>> Does this look ok? Kenny, can you double check the cases, think I have
> >>> them right, but? a double check would be good.
> >> That works for me.
> >>
> > i talked to mike a
On Oct 18, 2013, at 6:11 AM, Kenneth Zadeck wrote:
>>> Does this look ok? Kenny, can you double check the cases, think I have
>>> them right, but? a double check would be good.
>> That works for me.
>>
> i talked to mike about this last night, but did not follow up with an email
> until now.
On Fri, Oct 18, 2013 at 3:13 PM, Kenneth Zadeck
wrote:
> Richi,
>
> Do you want me to back out the patch that changes the rep for unsigned
> tree-csts?
Not yet please.
Thanks,
Richard.
> kenny
Richi,
Do you want me to back out the patch that changes the rep for unsigned
tree-csts?
kenny
On 10/18/2013 04:45 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Mike Stump wrote:
On Oct 17, 2013, at 1:46 AM, Richard Biener wrote:
[This function shows another optimization issue:
case BOOLEAN_TYPE:
/* Cache false or true. */
limit = 2;
if (wi::leu_p (cst, 1))
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
> On 10/17/2013 09:48 AM, Richard Biener wrote:
> > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> >
> > > Richard Biener writes:
> > > > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> > > >
> > > > > Richard Biener writes:
> > > > > > > The new tre
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
> On 10/17/2013 10:05 AM, Richard Sandiford wrote:
> > Richard Biener writes:
> > > > > What's the reason again to not use my original proposed encoding
> > > > > of the MSB being the sign bit? RTL constants simply are all signed
> > > > > then. Just y
On Thu, 17 Oct 2013, Mike Stump wrote:
> On Oct 17, 2013, at 1:46 AM, Richard Biener wrote:
> > [This function shows another optimization issue:
> >
> >case BOOLEAN_TYPE:
> > /* Cache false or true. */
> > limit = 2;
> > if (wi::leu_p (cst, 1))
> >ix = cst.to_uhwi ();
On Oct 17, 2013, at 1:46 AM, Richard Biener wrote:
> [This function shows another optimization issue:
>
>case BOOLEAN_TYPE:
> /* Cache false or true. */
> limit = 2;
> if (wi::leu_p (cst, 1))
>ix = cst.to_uhwi ();
>
> I would have expected cst <= 1 be optimized to cst
On 10/17/2013 10:05 AM, Richard Sandiford wrote:
Richard Biener writes:
What's the reason again to not use my original proposed encoding
of the MSB being the sign bit? RTL constants simply are all signed
then. Just you have to also sign-extend in functions like lts_p
as not all constants are
On 10/17/2013 09:48 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occ
On 10/17/2013 09:16 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tre
Richard Biener writes:
> What I see is really bad code for the simple integer-cst predicates
> in tree.c. I don't mind in what way we fix it, but avoiding the
> copy on every tree integer constant read looks required to me.
But we got rid of the copy with yesterday's patch. Are you talking
abou
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> >> > What's the reason again to not use my original proposed encoding
> >> > of the MSB being the sign bit? RTL constants simply are all signed
> >> > then. Just you have to also sign-extend in functions like lts_p
> >> >
Richard Biener writes:
>> > What's the reason again to not use my original proposed encoding
>> > of the MSB being the sign bit? RTL constants simply are all signed
>> > then. Just you have to also sign-extend in functions like lts_p
>> > as not all constants are sign-extended. But we can use b
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> >> The new tree representation can have a length greater than max_len
> >> >> for an unsigned tree constant that occupies a whole number o
Kenneth Zadeck writes:
>> it avoids a 2nd copy though, which shows nicely what was rummaging in
>> my head for the last two days - that the int_trais <> abstraction
>> was somehow at the wrong level - it should have been traits that
>> are specific to the storage model? or the above should use
>>
Richard Biener writes:
> On Thu, 17 Oct 2013, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> >> The new tree representation can have a length greater than max_len
>> >> for an unsigned tree constant that occupies a whole number of HWIs.
>> >> The tree representation of an unsigned 0x8000
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
> On 10/17/2013 07:30 AM, Richard Biener wrote:
> > Oh, so it was the tree rep that changed? _Why_ was it changed?
> > We still cannot use it directly from wide-int and the extra
> > word is redundant because we have access to TYPE_UNSIGNED (TREE_TYPE ()
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
> On 10/17/2013 08:29 AM, Richard Biener wrote:
> > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> >
> > > Richard Biener writes:
> > > > > The new tree representation can have a length greater than max_len
> > > > > for an unsigned tree constant that
On 10/17/2013 07:30 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Kenneth Zadeck writes:
As mentioned in my message yesterday, I thought your new way of canonising
unsigned tree constants meant
On 10/17/2013 08:29 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Richard Sandiford wrote:
Richard Biener writes:
The new tree representation can have a length greater than max_len
for an unsigned tree constant that occupies a whole number of HWIs.
The tree representation of an unsigned 0x80
On 10/17/2013 07:49 AM, Richard Biener wrote:
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> >> The new tree representation can have a length greater than max_len
> >> for an unsigned tree constant that occupies a whole number of HWIs.
> >> The tree representation of an unsigned 0x8000 is 0x00 0x80 0x00.
> >> When e
Richard Biener writes:
>> The new tree representation can have a length greater than max_len
>> for an unsigned tree constant that occupies a whole number of HWIs.
>> The tree representation of an unsigned 0x8000 is 0x00 0x80 0x00.
>> When extended to max_wide_int the representation is the same.
>
On Thu, 17 Oct 2013, Kenneth Zadeck wrote:
> On 10/17/2013 04:46 AM, Richard Biener wrote:
> > the case actually comes up on the ppc because they do a lot of 128 bit
> > math.I think i got thru the x86-64 without noticing this.
> > > Well, it'd be suspicious if we're directly using 128-bit num
On 10/17/2013 04:46 AM, Richard Biener wrote:
the case actually comes up on the ppc because they do a lot of 128 bit
math.I think i got thru the x86-64 without noticing this.
Well, it'd be suspicious if we're directly using 128-bit numbers
in addr_wide_int. The justification for the asserti
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 17 Oct 2013, Richard Sandiford wrote:
> >
> >> Kenneth Zadeck writes:
> >> >> As mentioned in my message yesterday, I thought your new way of
> >> >> canonising
> >> >> unsigned tree constants meant that there wa
Richard Biener writes:
> On Thu, 17 Oct 2013, Richard Sandiford wrote:
>
>> Kenneth Zadeck writes:
>> >> As mentioned in my message yesterday, I thought your new way of canonising
>> >> unsigned tree constants meant that there was always an upper zero bit.
>> >> Is that right?
>> > i believe this
On Thu, 17 Oct 2013, Richard Sandiford wrote:
> Kenneth Zadeck writes:
> >> As mentioned in my message yesterday, I thought your new way of canonising
> >> unsigned tree constants meant that there was always an upper zero bit.
> >> Is that right?
> > i believe this is correct.
> >> If so, xprecis
Kenneth Zadeck writes:
>> As mentioned in my message yesterday, I thought your new way of canonising
>> unsigned tree constants meant that there was always an upper zero bit.
>> Is that right?
> i believe this is correct.
>> If so, xprecision < precision is a no-op, because the number always
>> ha
On 10/16/2013 02:45 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
I note that we immediately return in the above case, so
if (precision < xprecision + HOST_BITS_PER_WIDE_INT)
{
len = wi::force_to_size (scratch, val, len, xprecision,
precision, UNSIGNED);
Kenneth Zadeck writes:
>> I note that we immediately return in the above case, so
>>
>>if (precision < xprecision + HOST_BITS_PER_WIDE_INT)
>> {
>>len = wi::force_to_size (scratch, val, len, xprecision,
>> precision, UNSIGNED);
>>return wi::storage_ref (scr
On Oct 16, 2013, at 8:47 AM, Kenneth Zadeck wrote:
>> To avoid code quality wreckage we have to implement a different way
>> of allocating the 'scratch' storage of wide_int_ref_storage
> I want richard and mike to be the people who respond to the next point.I
> am not a c++ person and all of
On 10/16/2013 09:55 AM, Richard Biener wrote:
Speaking in terms of a patch:
Index: tree.h
===
--- tree.h (revision 203690)
+++ tree.h (working copy)
@@ -5184,14 +5184,11 @@ wi::int_traits ::decompose (
Speaking in terms of a patch:
Index: tree.h
===
--- tree.h (revision 203690)
+++ tree.h (working copy)
@@ -5184,14 +5184,11 @@ wi::int_traits ::decompose (
/ HOST_BITS_PER_WIDE_INT);
unsigned in
44 matches
Mail list logo
