Hi,
I have here an updated patch, which improves two things:
First it moves debug code out to an extra patch, as suggested by Jakub.
Secondly, it fixes the checks on STACK_GROWS_DOWNWARD and
ARGS_GROW_DOWNWARD. Previously these used to be conditionally defined
symbols, but recently they were ch
Hi,
On Thu, 11 Jun 2015 13:17:47 +0200, Eric Botcazou wrote:
>
>> Other than that, as I said already in the PR, I'm in favor of applying it to
>> the trunk (only, not release branches) and watching for performance and/or
>> wrong-code issues, but Eric is against it. What do others think about it?
Hi,
On Thu, 11 Jun 2015 12:56:50, Richard Biener wrote:
>
> I also think we need to be conservative. I didn't look at the patch in detail
> to check whether we are indeed conservative here (what about offsets
> that are not visibly constant like for if (n> m) ... a[m];?).
>
we only handle constan
Hi,
On Thu, 11 Jun 2015 16:38:23, Richard Biener wrote:
>
> Sounds like a red-zone is not accounted for?
>
No, I know about the red-zone:
+#ifdef RED_ZONE_SIZE
+ HOST_WIDE_INT red_zone_size = RED_ZONE_SIZE;
+#else
+ HOST_WIDE_INT red_zone_size = 0;
+#endif
otherwise there would
On Thu, Jun 11, 2015 at 4:34 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 11 Jun 2015 12:57:34 +0200, Jakub Jelinek wrote:
>>
>> On Thu, Jun 11, 2015 at 12:38:40PM +0200, Bernd Edlinger wrote:
>>> On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
IMHO the
#if 0
#endif
stuf
Hi,
On Thu, 11 Jun 2015 12:57:34 +0200, Jakub Jelinek wrote:
>
> On Thu, Jun 11, 2015 at 12:38:40PM +0200, Bernd Edlinger wrote:
>> On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
>>>
>>> IMHO the
>>> #if 0
>>> #endif
>>> stuff doesn't belong to the patch.
>>>
>>
>> I just wanted to leave a hin
On Thu, Jun 11, 2015 at 01:17:47PM +0200, Eric Botcazou wrote:
> > Other than that, as I said already in the PR, I'm in favor of applying it to
> > the trunk (only, not release branches) and watching for performance and/or
> > wrong-code issues, but Eric is against it. What do others think about i
> Other than that, as I said already in the PR, I'm in favor of applying it to
> the trunk (only, not release branches) and watching for performance and/or
> wrong-code issues, but Eric is against it. What do others think about it?
Yes, I'm against it, I think that the patch will introduce more i
On Thu, Jun 11, 2015 at 12:38:40PM +0200, Bernd Edlinger wrote:
> On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
> >
> > IMHO the
> > #if 0
> > #endif
> > stuff doesn't belong to the patch.
> >
>
> I just wanted to leave a hint, how I debugged this function, and how
> to assess the performance
On Thu, Jun 11, 2015 at 12:38 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
>>
>> IMHO the
>> #if 0
>> #endif
>> stuff doesn't belong to the patch.
>>
>
> I just wanted to leave a hint, how I debugged this function, and how
> to assess the performance of th
Hi,
On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
>
> IMHO the
> #if 0
> #endif
> stuff doesn't belong to the patch.
>
I just wanted to leave a hint, how I debugged this function, and how
to assess the performance of the decision that is taken here.
I mean, the boot-strap would certainly pa
On Thu, Jun 11, 2015 at 09:42:38AM +0200, Bernd Edlinger wrote:
> it was exactly to the day one year ago, when I posted this patch the first
> time:
> [PATCH] PR rtl-optimization/61047:
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00996.html
>
> The PR was suspended, but the discussion did no
12 matches
Mail list logo
