https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416
--- Comment #6 from Wilco ---
(In reply to Andrew Pinski from comment #4)
> Actually I think the problem is (const_int 8 [0x8]) does that make sense
> for CC mode? I don't think it does.
It should make sense as a CCmode immediate. It relies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416
--- Comment #7 from Wilco ---
(In reply to Richard Henderson from comment #5)
> Created attachment 37419 [details]
> proposed patch
>
> I'm testing the following, but it does produce correct results
> on a spot check of emit-rtl.c:1833.
Yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #15 from Wilco ---
(In reply to Richard Henderson from comment #14)
> (In reply to Wilco from comment #12)
> > The only remaining question I had whether it would be possible to use
> > peephole expansions rather than the late splits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #12 from Wilco ---
(In reply to Wilco from comment #11)
> With your patch expand always emits add instructions with complex immediates
> which then can't be optimized.
OK, so I can change your patch do the right thing with 2 minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #11 from Wilco ---
(In reply to Richard Henderson from comment #10)
> Created attachment 37267 [details]
> proposed patch
>
> Andrew is exactly right re plus being special.
>
> The pluslong hoops that are being jumped through are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69176
--- Comment #9 from Wilco ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Wilco from comment #7)
> > > > I think the problem is the constraints on *add3_pluslong allows
> > > > all immediates.
> > >
> > > I'm not sure what you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #33 from Wilco ---
(In reply to Evandro from comment #32)
> (In reply to Ramana Radhakrishnan from comment #31)
> > (In reply to Evandro from comment #30)
> > > The performance impact of always referring to constants as if they were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66946
--- Comment #4 from Wilco wdijkstr at arm dot com ---
(In reply to Andrew Pinski from comment #2)
Comment on attachment 36021 [details]
minimal example
written == ((wchar_t) 0xfffd)
Will ever be true or is there some sign extending going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66946
--- Comment #1 from Wilco wdijkstr at arm dot com ---
Created attachment 36021
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36021action=edit
minimal example
Minimal example which still reports the spurious warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
Wilco wdijkstr at arm dot com changed:
What|Removed |Added
CC||wdijkstr at arm dot com
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
Created attachment 36016
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36016action=edit
preprocessed iso-2022-cn-ext.c
Since recently (around May) GCC6 has started to emit
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
The isinf, isnan, isnormal, isfinite, fpclassify and signbit builtins use FP
arithmetic to compute their result even with -fsignaling-nans (signbit only
when -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #1 from Wilco wdijkstr at arm dot com ---
Note when this is fixed, GLIBC math/math.h should be updated to enable the
isinf builtins even with -fsignaling-nans.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
--- Comment #13 from Wilco wdijkstr at arm dot com ---
(In reply to Vladimir Makarov from comment #9)
Created attachment 35503 [details]
ira-hook.patch
Here is the patch. Could you try it and give me your opinion about it.
Thanks.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
--- Comment #4 from Wilco wdijkstr at arm dot com ---
(In reply to Vladimir Makarov from comment #3)
But I can not just revert the patch making ALL_REGS available
to make
coloring heuristic more fotunate for your particular case, as it
reopens
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
As PR rtl-optimization/64151 showed, the longjmp expansion on i386 is incorrect
if the base register is spilled. It turns out it is trivial to write an example
that reproduces this without my patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151
--- Comment #7 from Wilco wdijkstr at arm dot com ---
See PR rtl-optimization/64242 for the longjmp issue on i386.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #3 from Wilco wdijkstr at arm dot com ---
(In reply to H.J. Lu from comment #2)
Dup of PR 59039?
No that talks about not using __builtin_setjmp and __builtin_longjmp within the
same function. I only used longjmp. Or are they so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64151
--- Comment #2 from Wilco wdijkstr at arm dot com ---
(In reply to H.J. Lu from comment #1)
Revert the reg_class change:
diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c
index 72c00cc..16fd6e8 100644
--- a/gcc/ira-costs.c
+++ b/gcc/ira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156
--- Comment #3 from Wilco wdijkstr at arm dot com ---
(In reply to Michael Meissner from comment #2)
Note, the fix proposed in PR64151 DOES NOT work on the PowerPC, so it may be
a dup in terms of what change broke the build, but the potential
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580
Wilco wdijkstr at arm dot com changed:
What|Removed |Added
CC||wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
Wilco wdijkstr at arm dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #22 from Wilco wdijkstr at arm dot com ---
(In reply to Evandro from comment #21)
(In reply to ramana.radhakrish...@arm.com from comment #20)
What's the kind of performance delta you see if you managed to unroll
the loop just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #24 from Wilco wdijkstr at arm dot com ---
(In reply to Evandro from comment #23)
(In reply to Wilco from comment #22)
Unrolling alone isn't good enough in sum reductions. As I mentioned before,
GCC doesn't enable any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #18 from Wilco wdijkstr at arm dot com ---
(In reply to Andrew Pinski from comment #17)
(In reply to Wilco from comment #16)
(In reply to Andrew Pinski from comment #13)
(In reply to Wilco from comment #9)
I committed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #15 from Wilco wdijkstr at arm dot com ---
(In reply to Evandro from comment #12)
(In reply to Evandro from comment #11)
Do you have an idea of the performance impact of this patch?
At least in Dhrystone, it improved by over 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #16 from Wilco wdijkstr at arm dot com ---
(In reply to Andrew Pinski from comment #13)
(In reply to Wilco from comment #9)
I committed a workaround
(http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #13 from Wilco wdijkstr at arm dot com ---
(In reply to Andrew Pinski from comment #11)
(In reply to Wilco from comment #10)
The loops shown are not the correct inner loops for those options - with
-ffast-math they are vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #15 from Wilco wdijkstr at arm dot com ---
(In reply to Evandro Menezes from comment #14)
Compiling the test-case above with just -O2, I can reproduce the code I
mentioned initially and easily measure the cycle count to run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
Wilco wdijkstr at arm dot com changed:
What|Removed |Added
CC||wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #10 from Wilco wdijkstr at arm dot com ---
(In reply to Andrew Pinski from comment #2)
https://gcc.gnu.org/ml/gcc/2014-05/msg00160.html
Note currently it is not possible to use FP registers for spilling using the
hooks - basically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #19 from Wilco wdijkstr at arm dot com ---
(In reply to Evandro from comment #16)
(In reply to Wilco from comment #15)
Using -Ofast is not any different from -O3 -ffast-math when compiling
non-Fortran code. As comment 10 shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
--- Comment #10 from Wilco wdijkstr at arm dot com ---
The loops shown are not the correct inner loops for those options - with
-ffast-math they are vectorized. LLVM unrolls 2x but GCC doesn't. So the
question is why GCC doesn't unroll vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503
Wilco wdijkstr at arm dot com changed:
What|Removed |Added
CC||wdijkstr at arm dot com
101 - 134 of 134 matches
Mail list logo
