On Wed, Nov 19, 2014 at 02:23:47PM -0800, Mike Stump wrote:
On Nov 19, 2014, at 1:57 PM, Jakub Jelinek ja...@redhat.com wrote:
Though, following patch is just fine for me too, I don't think it will
make a significant difference:
This version is fine by me.
Richard, are you ok with that
Jakub Jelinek ja...@redhat.com writes:
On Wed, Nov 19, 2014 at 02:23:47PM -0800, Mike Stump wrote:
On Nov 19, 2014, at 1:57 PM, Jakub Jelinek ja...@redhat.com wrote:
Though, following patch is just fine for me too, I don't think it will
make a significant difference:
This version is fine
On Tue, Nov 18, 2014 at 04:34:12PM -0800, Mike Stump wrote:
On Nov 18, 2014, at 3:42 PM, Jakub Jelinek ja...@redhat.com wrote:
No, I'm not touching tmp array at all in that case, only look at vp
individual bytes. Either they are all 0, or all 0xff, or I return NULL.
Oh, sorry, I misread
On Tue, 18 Nov 2014, Jakub Jelinek wrote:
Hi!
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not using CONST_WIDE_INT).
As the following testcase shows,
On Wed, Nov 19, 2014 at 09:59:45AM +0100, Richard Biener wrote:
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not using CONST_WIDE_INT).
As the following
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
On Wed, Nov 19, 2014 at 09:59:45AM +0100, Richard Biener wrote:
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not
On Wed, Nov 19, 2014 at 12:59:06PM +0100, Richard Biener wrote:
So perhaps something like this? Don't know how much more inefficient it is
compared to what it used to do before.
Yes, that looks good.
Or just keep the existing code and just remove the assert and instead return
NULL
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
On Wed, Nov 19, 2014 at 12:59:06PM +0100, Richard Biener wrote:
So perhaps something like this? Don't know how much more inefficient it
is
compared to what it used to do before.
Yes, that looks good.
Or just keep the existing code
On Nov 19, 2014, at 4:24 AM, Richard Biener rguent...@suse.de wrote:
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
is it still bound to wide_int (i.e.
On Nov 19, 2014, at 4:07 AM, Jakub Jelinek ja...@redhat.com wrote:
For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
is it still bound to wide_int (i.e. MAX_BITSIZE_MODE_ANY_INT rounded up)
Jakub Jelinek ja...@redhat.com writes:
On Wed, Nov 19, 2014 at 09:59:45AM +0100, Richard Biener wrote:
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not using
On Wed, Nov 19, 2014 at 10:38:57AM -0800, Mike Stump wrote:
On Nov 19, 2014, at 4:24 AM, Richard Biener rguent...@suse.de wrote:
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
about TARGET_SUPPORTS_WIDE_INT != 0, can it express
On Nov 19, 2014, at 1:57 PM, Jakub Jelinek ja...@redhat.com wrote:
Though, following patch is just fine for me too, I don't think it will
make a significant difference:
This version is fine by me.
--- gcc/simplify-rtx.c2014-11-19 15:39:24.073113107 +0100
+++ gcc/simplify-rtx.c
Hi!
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not using CONST_WIDE_INT).
As the following testcase shows, simplify_immed_subreg can be called
with such modes
On Nov 18, 2014, at 1:52 PM, Jakub Jelinek ja...@redhat.com wrote:
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not using CONST_WIDE_INT).
As the following
On Tue, Nov 18, 2014 at 03:30:56PM -0800, Mike Stump wrote:
Before wide-int got merged, the testcase worked, though the code didn't
bother checking anything, just created 0 or constm1_rtx for the two cases
that could happen and if something else appeared, could just return what
matched low
On Nov 18, 2014, at 3:42 PM, Jakub Jelinek ja...@redhat.com wrote:
No, I'm not touching tmp array at all in that case, only look at vp
individual bytes. Either they are all 0, or all 0xff, or I return NULL.
Oh, sorry, I misread where the break; in your code was going. I might have
been
17 matches
Mail list logo
