Hi Richard,
> On Thu, Jul 09, 2020 at 09:17:46AM +0100, Richard Sandiford wrote:
>> > +res = force_reg (mode, res);
>>
>> In general, this can be dangerous performance-wise on targets where
>> subregs are free. If the move survives to the register allocators,
>> it increases the
64-pc-linux-gnu, where SUBREGs are free, this patch generates
exactly the same builtin-arith-overflow-1.s as before.
This patch has been tested on both x86_64-pc-linux-gnu with
"make bootstrap" and nvptx-none with "make", with no new
testsuite regressions on either platform.
(a-b)+c. The hope is that
these mnemonics help ptxas generate the low-level hardware's IADD3 instruction.
Tested by "make" and "make -k check" on --build=nvptx-none hosted on
x86_64-pc-linux-gnu
with no new regressions.
[PATCH] nvptx: Add support for vadd.add and vsub.a
thanks for pointing out that the nvptx problem is PR target/90932.
Roger
--
-Original Message-
From: Tom de Vries
Sent: 02 July 2020 13:09
To: Roger Sayle ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] nvptx: Fix ICE in nvptx_vector_alignment on
gcc.dg/attr-vector_size.c
On 6/29/20 7
t;make -k check" on --build=nvptx-none hosted on
x86_64-pc-linux-gnu with
no new regressions.
2020-07-01 Roger Sayle
gcc/ChangeLog:
* config/nvptx/nvptx.md (popcount2): New instructions.
(mulhishi3, mulsidi3, umulhisi3, umulsidi3): New instructions.
gcc
e the code itself.
OK for mainline? Thanks in advance to anyone who can confirm this patch
resolves the unexpected failure of gcc.dg/attr-vector_size.c on an affected
platform (i.e. a backend that doesn't define TARGET_VECTOR_ALIGNMENT).
2020-06-30 Roger Sayle
PR middle-end/90597
gcc
-time error messages.
Tested on --target=nvptx-none, with a "make" and "make check" which results in
four
fewer unexpected failures and three more expected passes.
Ok for mainline?
2020-06-29 Roger Sayle
gcc/ChangeLog:
* config/nvptx/nvptx.c (nvptx_vector_alignmen
as committed. I've added the (xor (ashiftrt x c) (ashiftrt y c))
case as per your
suggestion, which fires 6 times during make -k check on x86_64-pc-linux-gnu.
Cheers,
Roger
--
-Original Message-
From: Richard Sandiford
Sent: 22 June 2020 20:41
To: Roger Sayle
Cc: gcc-patches@gcc.gnu.org
Hi Segher,
It's great to hear from you again. It's been a while.
>On Fri, Jun 19, 2020 at 09:42:54PM +0100, Roger Sayle wrote:
>> My recent patch to add scalar integer simplification unit tests to
>> simplify_rtx_c_tests identified two "trivial" corner cas
and "make -k check"
on x86_64-pc-linux-gnu with no regressions.
2020-06-19 Roger Sayle
* simplify-rtx.c (simplify_unary_operation_1): Simplify
(parity (parity x)) as (parity x), i.e. PARITY is idempotent.
(simplify_binary_operation_1): Don't canonicalize r
covery plan.
This patch has been tested with "make bootstrap" and "make -k check"
on x86_64-pc-linux-gnu with no regressions.
2020-06-16 Roger Sayle
Richard Sandiford
* simplify-rtx.c (simplify_distributive_operation): New function
to un-distribute
eviewer could commit this change for me.
2020-06-14 Roger Sayle
* trans-intrinsic.c (gfc_conv_intrinsic_popcnt_poppar): Translate
poppar(kind=16) as parityll(hipart(x)^lopart(x)) instead of
parityll(hipart(x))^parityll(lopart(x)).
Thanks in advance,
Roger
--
R
"make -k check" on
x86_64-pc-linux-gnu with no regressions. If approved, I'd very much
appreciate it if someone could commit this change for me.
2020-06-12 Roger Sayle
* match.pd (popcount(x)&1 -> parity(x)): New simplification.
(parity(~x) -&
d commit this change for me.
2020-06-11 Roger Sayle
* simplify-rtx.c (simplify_binary_operation_1): Simplify
(X & C) ^ (Y & C) to (X ^ Y) & C, when C is simple (i.e. a
constant).
Thanks very much in advance,
Roger
--
Roger Sayle
NextMove Softwa
hanks in advance,
Roger
--
2020-06-05 Roger Sayle
* config/i386/i386.md (paritydi2, paritysi2): Expand reduction
via shift and xor to an USPEC PARITY matching a parityhi2_cmp.
(paritydi2_cmp, paritysi2_cmp): Delete these define_insn_and_split.
st cases.
Many thanks In advance. Best regards,
Roger
--
Roger Sayle, PhD.
NextMove Software Limited
Innovation Centre (Unit 23), Cambridge Science Park, Cambridge, CB4 0EY
2018-02-09 Roger Sayle <ro...@nextmovesoftware.com>
* fold-const.c (tree_nonzero_bits): New
advance and apologies for any
inconvenience].
2018-01-14 Roger Sayle <ro...@nextmovesoftware.com>
* config/arm/arm.md (*arm_zeroextractsi2_8_8,
*arm_signextractsi2_8_8,
*arm_zeroextractsi2_8_16, *arm_signextractsi2_8_16,
*arm_zeroextractsi2_16_8, *arm_signextractsi2_
.
Most of this patch is the resulting re-indentation.
Test on x86_64-pc-linux-gnu with "make bootstrap" and "make check" with no
regressions.
Ok for mainline?
2016-08-05 Roger Sayle <ro...@nextmovesoftware.com>
PR middle-end/21137
* fold-const.c
to be addressed as follow-up patches and therefore
regression fixes suitable for stage 3?
Congratulations again to Michael for this impressive performance
improvement.
Roger
--
Roger Sayle, Ph.D.
OpenEye Scientific Software,
Suite #D, 9 Bisbee Court,
Santa Fe, New Mexico, 87508.
Hi Manuel and Paolo,
On Sun, January 14, 2007 3:59 pm, Paolo Carlini wrote:
By the way, new also wrt current 4_2-branch, in the sense that the
latter doesn't emit *any* overflow warning for the snippet in 30465,
with explicit -Wconversion too...
I think I can explain everything. The first
On Tue, 31 Oct 2006, Dave Korn wrote:
Tracking down a gcse bug while unrolling a loop where the count is
known to be one, I've narrowed the problem down to the actions of
commit_edge_insertions and bypass_conditional_jumps, and I could use
a little help in appreciating the reasoning behind
Hi Paolo,
On Mon, 30 Oct 2006, Paolo Bonzini wrote:
Given that Roger started the ball rolling, by approving Steven's
-fcse-skip-blocks patch, I'll ping the discussion...
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01066.html
I believe the appropriate next step is to freshen these patches
Hi Andrew,
On Wed, 25 Oct 2006, Andrew Haley wrote:
I must admit to being a little perplexed by this.
We have an unsafe optimization that causes bad code to be generated on
at least one platform. However, we want to continue to perform this
unsafe optimization on our release branch until
On Wed, 25 Oct 2006, Richard Sandiford wrote:
Roger Sayle [EMAIL PROTECTED] writes:
Once explained, I'd expect most maintainers would make precisely the
same call?
I suppose the counter-argument is that we shouldn't ship 4.2 in its
current state. We should either back out the patch
Hi Denis,
On Mon, 31 Jul 2006, Jim Wilson wrote:
At the moment, there is probably no one who understands this code as
well as you do, so you may not get much help from others.
In my defence, I'm struggling to get up to speed with all of the
issues. The first and obvious comments are that
Hi Ian,
On Sun, 9 Jul 2006, Ian Blanes wrote:
I've been recently looking at the splay tree implementation. I've noticed
that this revision http://gcc.gnu.org/viewcvs?view=revrevision=106584
does a strange splaying. It does a bottom up splaying but starting at the
root (not the same that top
with the following patch. Committed to mainline as obvious as
revision 115076, after a full 3-stage bootstrap of the gcc/ directory
on x86_64-unknown-linux-gnu.
My apologies yet again for the breakage, and especially to Mark.
2006-06-29 Roger Sayle [EMAIL PROTECTED]
* genpreds.c
On Fri, 19 May 2006, Mark Mitchell wrote:
I'm evaluating the options. It would be helpful if someone has time to
apply and test Richard's patch on 4.1, as that would let us know whether
that option is viable as well.
I've bootstrapped and regression tested a backport of Richard's patch
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
for MIPS on the GCC 4.1 branch?
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem
Hi Richard,
On Fri, 19 May 2006, Richard Sandiford wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem to be a PR;
Richard indicated to me that he would locate or
On Fri, 19 May 2006, Mark Mitchell wrote:
No, you can invoke it via using the attribute mode(TI)
Sure, but I'm not worried about that case.
That would be the only class of C or C++ failures that I could easily
construct by hand. Although the RTL optimizers will introduce TImode
moves and
Hi Mircea,
On Fri, 5 May 2006, Mircea Namolaru wrote:
That certainly does suggest a bug in the SEE patches. They needn't do
anything useful on IA32/AMD64, but they should presumably either (a) not
cause a bootstrap failure on these architectures, or (b) be disabled on
these
Hi Mark,
On Tue, 2 May 2006, Mark Mitchell wrote:
Roger, I know that you reviewed the SEE patches. Is there anything
more than needs to be done to get them committed, in your view?
As far as I'm aware, we're still just waiting for the Haifa folks to
commit them to mainline. There are a
I've a quick question regarding the policy for granting/sponsoring
CVS/subversion write access. There seems to have been a recent
change in thinking (or difference of opinions) on the pre-requisites
for allowing a new contributor modification rights to GCC's source
repository.
My understanding
On Thu, 6 Apr 2006, Daniel Bratell wrote:
that it would be safe to use that flag unless I relied on extreme
precision or behaviour related to NaN or +-Inf, and that normal simple
arithmetics should still give the same result.
Unfortunately, with -ffast-math simple arithemtics no longer have
On Mon, 3 Apr 2006, Richard Guenther wrote:
negate_expr_p currently contains
...
where it looks bogus to simply return true for signed types but
unset flag_trapv.
...
which is bogus as it should read || (!flag_trapv flag_wrapv) - no?
I hit this with a patch to fold A +- CST to A -+ CST
On Mon, 3 Apr 2006, Richard Guenther wrote:
|| (TREE_CODE (type) == INTEGER_TYPE
(TREE_CODE (arg1) == INTEGER_CST
|| TYPE_UNSIGNED (type)
|| (flag_wrapv !flag_trapv)))
Does this sound reasonable?
Yes, this sounds
On Sun, 2 Apr 2006, Eric Botcazou wrote:
2006-04-01 Roger Sayle [EMAIL PROTECTED]
* tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
[...]
(int_size_in_bytes): Likewise.
(host_integerp): Likewise.
Is this an oversight?
Doh. Indeed. The last two lines
is whether everyone agrees that we're ready for
such a step. Is such a transition safe for stage 3 mainline,
and/or would front-ends prefer some time to double check that
this won't cause problems on conformance tests not part of GCC's
testsuite.
Thoughts?
2006-04-01 Roger Sayle [EMAIL PROTECTED
On Mon, 27 Mar 2006, [UTF-8] Rafael Esp??ndola wrote:
I have put toghether a hack to remove the convert callback. It consists in
1) adding a lang prefix to the implementations of convert (cxx_, c_,
gfc_, etc)
2) defining a convert2 function that is basically a copy of c_convert
3)
On Thu, 2 Mar 2006, Jeffrey A Law wrote:
Is causing 961206-1.c to regress at -O1 and -O2 on i686-pc-linux-gnu
and possibly other platforms.
Doh! This doesn't fail on x86_64-unknown-linux-gnu, where I developed
that patch, but I am now seeing those failures on i686-pc-linux-gnu.
OUCH.
I've a IA-32 backend question on the intended behaviour of the functions
ix86_binary_operator_ok and ix86_fixup_binary_operands.
My confusion is that these functions currently allow arithmetic
operations of the form reg = op(mem,immed) even though this
shape isn't supported by x86 ISA. For
On Mon, 23 Jan 2006, Paolo Bonzini wrote:
2006-01-23 Paolo Bonzini [EMAIL PROTECTED]
PR rtl-optimization/25890
PR rtl-optimization/25905
* combine.c (expand_compound_operation, expand_field_assignment):
Fail if the bitfield's final position is out of bounds.
This
hour rule
where we reinstate Zdenek's patch on Monday, either by fixing DF
by then or by reverting the DF changes. i.e. swap one of the clashing
patches for the other.
My apologies to everyone for any inconvenience. Many thanks to Dan
and H-P for investigating the problem on IRC.
Roger
--
Roger
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
I propose the following workaround instead, that also restores
bootstrap. It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
That's what I like to see... options. Yes, this is OK for mainline,
please
Hi Diego,
On Thu, 12 Jan 2006, Diego Novillo wrote:
In fold_binary() we are asserting:
gcc_assert (IS_EXPR_CODE_CLASS (kind)
TREE_CODE_LENGTH (code) == 2
op0 != NULL_TREE
op1 != NULL_TREE);
...
DEFTREECODE (OMP_SINGLE, omp_single,
was hoping that progress on killing loop.c would have
progressed to the point that this change would be a trivial
tweak to want_to_gcse_p, but alas this modification is encumbered
by a few minor changes to the soon-to-be obsolete loop.c]
Thoughts?
2005-12-27 Roger Sayle [EMAIL PROTECTED
Hi Dan,
On Wed, 7 Dec 2005, Daniel Berlin wrote:
This is *already* wrong, AFAICT, because reg:QI 58 is uninitialized, and
we are trying to use it's value. Why do we do this?
This may have been a rhetorical question, but the middle-end's RTL
expanders are generating uses of uninitialized
On Thu, 1 Dec 2005, Richard Guenther wrote:
It looks like it is safe to exchange both of them (the first one for sure)
to fold_convert (...) due to the fact that fold_unary handles NOP_EXPR
the same way than CONVERT_EXPR apart from cases that look like oversights,
...
In fact, I remember a
On Mon, 22 Aug 2005, Dale Johannesen wrote:
There is some clever code in convert_to_real that converts
double d;
(float)floor(d)
to
floorf((float)d)
...
Comments? Should I preserve the buggy behavior with -ffast-math?
Good catch. This is indeed a -ffast-math (or more precisely a
On Sun, 21 Aug 2005, Leehod Baruch wrote:
*** 329,334
--- 328,341
GET_MODE (SUBREG_REG (x)),
SUBREG_BYTE (x));
return op0 ? op0 : x;
+ }
+ if (code == SET)
+ {
+ op0 =
On Sun, 29 May 2005, Steven Bosscher wrote:
I don't understand what lines 2728 to 2741 are for. Could someone give
an example of when we can have a then_bb that has no successors, but
still ends in something that satisfies simplejump_p()? What kind of
strange indirect jump would that be?
On Thu, 26 May 2005, Scott Robert Ladd wrote:
I prefer breaking out the hardware intrinsics from
-funsafe-math-optimizations, such that people can compile to use their
hardware *without* the other transformations implicit in the current
collective.
If someone can explain how this hurts
On Sun, 15 May 2005, Richard Guenther wrote:
What can be done about this issues? First, we can use VIEW_CONVERT_EXPR
unconditionally in fold_indirect_ref and only break some optimizations
(like temp1.C). Second, we can declare fold_indirect_ref being unsafe
about types and deal with this in
On Sun, 15 May 2005, Richard Guenther wrote:
Exactly which optimization do we miss by changing:
/* *p = p */
- if (lang_hooks.types_compatible_p (type, optype))
+ if (type == optype)
return op;
I don't know - maybe stripping sign casts. But if we use equality
in advance,
Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
On 30 Apr 2005, Gabriel Dos Reis wrote:
There were 36 PRs open against it (as of this morning, 6am, GMT-05).
I wnet through all of them and the appeared to be very minor or
impossible bugs to fix in 3.3.6 major restructuring (typically, they
were bugs fixed in 3.4.x or 4.0.x). Two of them
On Mon, 18 Apr 2005, Paolo Bonzini wrote:
Roger proposed lowering 64-bit arithmetic to 32-bit in tree-ssa! How
would you do it? Take
long long a, b, c;
c = a + b;
Would it be
c = ((int)a + (int)b)
+ ((int) (a 32) + (int) (b 32)
+ ((unsigned int)
On Sat, 16 Apr 2005, Richard Kenner wrote:
Although, RTL expansion may introduce new loops, these tend to be
rare, and the expanders have all the information they need to
hoist/sink invariant expressions and unroll/peel themselves.
I disagree. In order to make the proper
I seem to have inadvertantly annoyed Steven Bosscher on IRC,
so by way of an apology and explanation I thought I'd post my current
opinion and thinking on the optimizations performed by GCC's middle-end
both at the tree-level in the tree-ssa optimizers and at the
RTL-level in the exisiting
On Mon, 7 Mar 2005, Mark Mitchell wrote:
Roger Sayle wrote:
For example, I believe that Alex's proposed solution to PR c++/19199
isn't an appropriate fix. It's perfectly reasonable for fold to convert
a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
front-end all
On Thu, 3 Mar 2005, Kazu Hirata wrote:
If we want to change fold_builtin to take operands like op0, op1, and
op2, I would have to change so many things that depend on
fold_builtin. (Note that the subroutines of fold_builtin also depends
on fold_builtin in a sense that they need the original
I should probably also add that if any of the branches scheduled for
merge prior to 4.1 contain/require changes to fold, perhaps for
additional transformations they need, I'll be glad to review/approve
those specific changes now, ahead of their branch's planned merge dates
to allow them to
601 - 663 of 663 matches
Mail list logo
