On Thu, 17 Sep 2015, Alan Lawrence wrote:
> On 15/09/15 08:43, Richard Biener wrote:
> >
> > Sorry for chiming in so late...
>
> Not at all, TYVM for your help!
>
> > TREE_CONSTANT isn't the correct thing to test. You should use
> > TREE_CODE () == INTEGER_CST instead.
>
> Done (in some
On 15/09/15 08:43, Richard Biener wrote:
>
> Sorry for chiming in so late...
Not at all, TYVM for your help!
> TREE_CONSTANT isn't the correct thing to test. You should use
> TREE_CODE () == INTEGER_CST instead.
Done (in some cases, via tree_fits_shwi_p).
> Also you need to handle
> NULL_TREE
On Mon, 14 Sep 2015, Alan Lawrence wrote:
> Ping. (Rerevert with 5 lines extra paranoia in scalarizable_type_p).
Sorry for chiming in so late...
+ if (TYPE_DOMAIN (type) == NULL_TREE
+ || !TREE_CONSTANT (TYPE_MIN_VALUE (TYPE_DOMAIN (type)))
+ || !TREE_CONSTANT
Ping. (Rerevert with 5 lines extra paranoia in scalarizable_type_p).
Thanks, Alan
On 08/09/15 13:43, Martin Jambor wrote:
Hi,
On Mon, Sep 07, 2015 at 02:15:45PM +0100, Alan Lawrence wrote:
In-Reply-To: <55e0697d.2010...@arm.com>
On 28/08/15 16:08, Alan Lawrence wrote:
Alan Lawrence wrote:
Hi,
On Mon, Sep 07, 2015 at 02:15:45PM +0100, Alan Lawrence wrote:
> In-Reply-To: <55e0697d.2010...@arm.com>
>
> On 28/08/15 16:08, Alan Lawrence wrote:
> > Alan Lawrence wrote:
> >>
> >> Right. I think VLA's are the problem with pr64312.C also. I'm testing a fix
> >> (that declares arrays with
In-Reply-To: <55e0697d.2010...@arm.com>
On 28/08/15 16:08, Alan Lawrence wrote:
> Alan Lawrence wrote:
>>
>> Right. I think VLA's are the problem with pr64312.C also. I'm testing a fix
>> (that declares arrays with any of these properties as unscalarizable).
> ...
> In the meantime I've reverted
On Fri, 28 Aug 2015, Christophe Lyon wrote:
On 27 August 2015 at 17:43, Alan Lawrence alan.lawre...@arm.com wrote:
Martin Jambor wrote:
First, I would be much
happier if you added a proper comment to scalarize_elem function which
you forgot completely. The name is not very descriptive
On 27 August 2015 at 17:43, Alan Lawrence alan.lawre...@arm.com wrote:
Martin Jambor wrote:
First, I would be much
happier if you added a proper comment to scalarize_elem function which
you forgot completely. The name is not very descriptive and it has
quite few parameters too.
Second,
On Fri, 28 Aug 2015, Christophe Lyon wrote:
On 28 August 2015 at 09:48, Richard Biener rguent...@suse.de wrote:
On Fri, 28 Aug 2015, Christophe Lyon wrote:
On 27 August 2015 at 17:43, Alan Lawrence alan.lawre...@arm.com wrote:
Martin Jambor wrote:
First, I would be much
happier
On 28 August 2015 at 09:48, Richard Biener rguent...@suse.de wrote:
On Fri, 28 Aug 2015, Christophe Lyon wrote:
On 27 August 2015 at 17:43, Alan Lawrence alan.lawre...@arm.com wrote:
Martin Jambor wrote:
First, I would be much
happier if you added a proper comment to scalarize_elem
Christophe Lyon wrote:
I asked because I assumed that Alan saw it pass in his configuration.
Bah. No - I now discover a problem in my C++ testsuite setup that was causing a
large number of tests to not be executed. I see the problem too now,
investigating
--Alan
Richard Biener wrote:
On Fri, 28 Aug 2015, Alan Lawrence wrote:
Christophe Lyon wrote:
I asked because I assumed that Alan saw it pass in his configuration.
Bah. No - I now discover a problem in my C++ testsuite setup that was causing
a large number of tests to not be executed. I see the
On Fri, 28 Aug 2015, Alan Lawrence wrote:
Christophe Lyon wrote:
I asked because I assumed that Alan saw it pass in his configuration.
Bah. No - I now discover a problem in my C++ testsuite setup that was causing
a large number of tests to not be executed. I see the problem too now,
Alan Lawrence wrote:
Right. I think VLA's are the problem with pr64312.C also. I'm testing a fix
(that declares arrays with any of these properties as unscalarizable).
Monday is a bank holiday in UK and so I expect to get back to you on Tuesday.
--Alan
In the meantime I've reverted the
Jeff Law wrote:
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/sra-15.c
b/gcc/testsuite/gcc.dg/tree-ssa/sra-15.c
new file mode 100644
index 000..e251058
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/sra-15.c
@@ -0,0 +1,38 @@
+/* Verify that SRA total scalarization works on records
Martin Jambor wrote:
First, I would be much
happier if you added a proper comment to scalarize_elem function which
you forgot completely. The name is not very descriptive and it has
quite few parameters too.
Second, this patch should also fix PR 67283. It would be great if you
could
On August 26, 2015 6:08:55 PM GMT+02:00, Alan Lawrence alan.lawre...@arm.com
wrote:
Richard Biener wrote:
One extra question is does the way we limit total scalarization
work
well
for arrays? I suppose we have either sth like the maximum size of
an
aggregate we scalarize or the maximum
On Tue, Aug 25, 2015 at 11:44 PM, Jeff Law l...@redhat.com wrote:
On 08/25/2015 03:42 PM, Martin Jambor wrote:
Hi,
On Tue, Aug 25, 2015 at 12:06:14PM +0100, Alan Lawrence wrote:
This changes the completely_scalarize_record path to also work on arrays
(thus
allowing records containing
Richard Biener wrote:
One extra question is does the way we limit total scalarization work
well
for arrays? I suppose we have either sth like the maximum size of an
aggregate we scalarize or the maximum number of component accesses
we create?
Only the former and that would be kept intact.
On August 26, 2015 11:30:26 AM GMT+02:00, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Wed, Aug 26, 2015 at 09:07:33AM +0200, Richard Biener wrote:
On Tue, Aug 25, 2015 at 11:44 PM, Jeff Law l...@redhat.com wrote:
On 08/25/2015 03:42 PM, Martin Jambor wrote:
Hi,
On Tue, Aug 25, 2015 at
Hi,
On Wed, Aug 26, 2015 at 09:07:33AM +0200, Richard Biener wrote:
On Tue, Aug 25, 2015 at 11:44 PM, Jeff Law l...@redhat.com wrote:
On 08/25/2015 03:42 PM, Martin Jambor wrote:
Hi,
On Tue, Aug 25, 2015 at 12:06:14PM +0100, Alan Lawrence wrote:
This changes the
On 08/25/2015 05:06 AM, Alan Lawrence wrote:
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing type_consists_of_records_p and completely_scalarize_record methods
to handle things of
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing type_consists_of_records_p and completely_scalarize_record methods
to handle things of ARRAY_TYPE as well as RECORD_TYPE. Hence, I
Hi,
On Tue, Aug 25, 2015 at 12:06:14PM +0100, Alan Lawrence wrote:
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing type_consists_of_records_p and completely_scalarize_record
On 08/25/2015 03:42 PM, Martin Jambor wrote:
Hi,
On Tue, Aug 25, 2015 at 12:06:14PM +0100, Alan Lawrence wrote:
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing
25 matches
Mail list logo