in DImode (in addition to the
vector modes already supported) and retains the support for doing
bitwise not in core registers where appropriate.
OK for 4.8?
Andrew
2012-02-29 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.md (one_cmpldi2): Rename to one_cmpldi2_internal
and replace
Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.c (neon_valid_immediate): Allow const_int.
* config/arm/constraints.md (Dn): Allow const_int.
* config/arm/neon.md (neon_movmode): Use VDX to allow DImode.
* config/arm/predicates.md (imm_for_neon_mov_operand): Allow const_int
combined with my recent patch for
NEON DImode immediates. Without that you get a constant pool load.)
OK for 4.8?
Andrew
2012-02-28 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.md (negdi2): Use gen_negdi2_neon.
* config/arm/neon.md (negdi2_neon): New insn_and_split.
---
gcc/config
On 21/02/12 15:23, Andrew Stubbs wrote:
On 06/02/12 13:13, Andrew Stubbs wrote:
This patch adds DImode shift support in NEON registers/instructions.
The patch causes delays any lowering until the split2 pass, after the
register allocator has chosen whether to do the shift in NEON (VFP
I'm not sure there's any advantage.
2012-02-23 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.md (zero_extendmodedi2): Add extra alternatives
for NEON registers.
(extendmodedi2): Likewise.
Prevent extend splitters doing NEON alternatives.
* config/arm/iterators.md
On 06/02/12 13:13, Andrew Stubbs wrote:
This patch adds DImode shift support in NEON registers/instructions.
The patch causes delays any lowering until the split2 pass, after the
register allocator has chosen whether to do the shift in NEON (VFP)
registers, or in core-registers.
The core
On 14/02/12 18:00, Andrew Stubbs wrote:
On Tue 14 Feb 2012 17:35:36 GMT, Richard Earnshaw wrote:
Bernds checked in a patch last year (or maybe even before that) to make
the selection of flags clobbered insns run very late (certainly after
condexec had run), so I'm not sure why you're not seeing
On 16/02/12 15:33, Andrew Stubbs wrote:
OK for 4.8?
I forgot to address Ramana's comment about optimize_size.
This update fixes that and leaves everything else untouched.
OK?
Andrew
2012-02-17 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm-protos.h
On 11/02/12 01:11, Richard Henderson wrote:
On 02/08/2012 08:28 AM, Andrew Stubbs wrote:
Unfortunately, these don't work in Thumb mode (no IT block), and I'd have to
add arith-shift variants, I think, for ARM mode to work.
H ... I'll try again.
Does it work to simply use branches
On 07/02/12 22:19, Ramana Radhakrishnan wrote:
I find it interesting that cond_exec's in this form survive all the
way till reload and work. AFAIK we could never have cond_exec's
before reload . The documentation doesn't appear to mention this,
therefore I would like to see if the cond_exec's
On 08/02/12 11:18, Andrew Stubbs wrote:
I've tried to do this, but it can't be done by a straight translation
because we don't have the insns available to do it. As I understand it,
all predicable instructions automatically get a cond_exec variant, but
the only if_then_else I could find (it's
On Mon 06 Feb 2012 13:18:34 GMT, Jakub Jelinek wrote:
On Mon, Feb 06, 2012 at 01:13:58PM +, Andrew Stubbs wrote:
Anyway, is this patch OK?
Are you asking approval for 4.8, or 4.7? For the latter this doesn't
seem to be a regression bugfix that would be suitable for stage4.
Yes, sorry
this, or not. I'm not even sure if it isn't the right choice
much of the time, cost wise.
Anyway, is this patch OK?
Andrew
2012-02-06 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.c (arm_print_operand): Add new 'E' format code.
* config/arm/arm.h (enum reg_class): Add
hadn't considered that. Good point!
This updated patch causes it to fall back to the old behaviour in
optimize_size mode. This should do what you want.
OK?
Andrew
2012-01-31 Andrew Stubbs a...@codesourcery.com
* config/arm/arm-protos.h (arm_emit_coreregs_64bit_shift): New
prototype.
* config
for stage 1?
Andrew
2012-01-27 Andrew Stubbs a...@codesourcery.com
* config/arm/arm-protos.h (arm_emit_coreregs_64bit_shift): New
prototype.
* config/arm/arm.c (arm_emit_coreregs_64bit_shift): New function.
* config/arm/arm.md (ashldi3): Use arm_emit_coreregs_64bit_shift.
(ashrdi3,lshrdi3
On 06/01/12 10:23, Ramana Radhakrishnan wrote:
OK
Committed.
Andrew
This patch fixes a testcase that fails whenever 120 appears in the
date. I first noticed the problem at the start of December, and now I
expect it to return and continue until the end of September, if it's not
fixed.
OK?
Andrew
2012-01-05 Andrew Stubbs a...@codesourcery.com
gcc/testsuite
On 07/12/11 13:42, Richard Earnshaw wrote:
So it looks like the code generated for core registers with thumb2 is
pretty rubbish (no real surprise there -- to get the best code you need
to make use of the fact that on ARM a shift by a small negative number
( -128) will give zero. This gives us
On 06/12/11 23:07, Richard Henderson wrote:
On 12/06/2011 01:42 PM, Andrew Stubbs wrote:
On Tue 06 Dec 2011 21:05:30 GMT, Richard Henderson wrote:
On 12/06/2011 09:59 AM, Andrew Stubbs wrote:
+(define_insn *one_cmpldi2_neon
+ [(set (match_operand:DI 0 s_register_operand =w,?r,?r,?w
On Wed 07 Dec 2011 13:42:37 GMT, Richard Earnshaw wrote:
So it looks like the code generated for core registers with thumb2 is
pretty rubbish (no real surprise there -- to get the best code you need
to make use of the fact that on ARM a shift by a small negative number
( -128) will give zero.
On Wed 07 Dec 2011 14:20:43 GMT, Richard Earnshaw wrote:
Would it not require an unspec to prevent 'clever things' happening to
the negative shift, if we were to encode these in the machine
description? I'm not too clear on what these 'clever things' might be in
the case of shift-by-register
input and one output, there's no
need for the
earlyclobber marker when the input is tied to the output (there's no other
operand that can be
clobbered).
Otherwise OK.
Thanks I'll test and commit the attached updated patch once stage 1
opens again.
Andrew
2011-12-07 Andrew Stubbs
using a mode
iterator that includes DI because it needs to coexist with the non-neon
one_cmpldi2 (renamed by this patch to one_cmpldi2_core).
OK for when stage 1 opens again?
Andrew
2011-12-06 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.md (one_cmpldi2): Rename
On Tue 06 Dec 2011 18:43:05 GMT, Julian Brown wrote:
On Tue, 06 Dec 2011 17:59:44 +
Andrew Stubbsa...@codesourcery.com wrote:
This patch adds a one's complement pattern for doing DImode 'not' in
NEON registers.
There are already patterns for doing one's complement of vectors, and
even
On Tue 06 Dec 2011 21:05:30 GMT, Richard Henderson wrote:
On 12/06/2011 09:59 AM, Andrew Stubbs wrote:
+(define_insn *one_cmpldi2_neon
+ [(set (match_operand:DI 0 s_register_operand =w,?r,?r,?w)
+ (not:DI (match_operand:DI 1 s_register_operand w, 0, r, w)))]
alternative 0
Hi All,
I'm trying to implement DImode shifts using ARM NEON instructions. This
wouldn't be difficult in itself, but making it play nice with the
existing implementation is causing me problems. I'd like a few
suggestions/pointers/comments to help me get this right, please.
The existing
On 26/10/11 10:15, Richard Earnshaw wrote:
Here's an updated patch that makes no generalizations.
OK?
Yep
Committed.
Andrew
an updated patch that makes no generalizations.
OK?
Andrew
2011-10-26 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -58,6 +58,7 @@
#define BE8_LINK_SPEC \
%{mbig-endian
My recent patch to add -mcpu=generic-armv7-a omitted support for big
endian. This patch should solve that.
As far as I know the only this missing is the linker spec. (I have no
big-endian targets to test with.)
OK?
Andrew
2011-10-25 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm
On 25/10/11 13:19, Richard Earnshaw wrote:
2011-10-25 Andrew Stubbsa...@codesourcery.com
gcc/
* config/arm/bpabi.h (BE8_LINK_SPEC): Recognize generic-armv7 tuning.
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -58,6 +58,7 @@
#define BE8_LINK_SPEC \
I've just committed this patch to fix PR50809, in which driver-arm.c
failed to build with a C++ compiler and -Werror.
The patch is pre-approved by Ramana, and anyway probably qualifies as
obvious.
Andrew
2011-10-21 Andrew Stubbs a...@codesourcery.com
PR target/50809
gcc/
* config/arm
On 18/10/11 15:42, Andrew Stubbs wrote:
Which still jumps to not_found without closing f.
Hmmm, I know I fixed that, I know I did!
But I appear to have lost the change somewhere when I updated my checkout?
I'll fix it now.
Fixed and committed as attached.
Apologies for the cock-up
with the second issue resolved.
Thanks, fixed and committed, as attached.
Andrew
2011-10-18 Andrew Stubbs a...@codesourcery.com
gcc/
* config.host (arm*-*-linux*): Add driver-arm.o and x-arm.
* config/arm/arm.opt: Add 'native' processor_type and
arm_arch enum values.
* config/arm/arm.h
On 18/10/11 15:34, Richard Earnshaw wrote:
On 18/10/11 15:23, Andrew Stubbs wrote:
+ /* Detect arch/cpu. */
+ if (strncmp (buf, CPU part, sizeof (CPU part) - 1) == 0)
+ {
+ int i;
+
+ if (cpu_table == NULL)
+ goto not_found;
+
Which still jumps
On 17/10/11 11:43, Richard Guenther wrote:
Ok.
Committed, thanks.
Andrew
Ping.
On 20/09/11 11:51, Andrew Stubbs wrote:
On 09/09/11 12:55, Richard Earnshaw wrote:
The part number field is meaningless outside of the context of a a
specific vendor -- only taken as a pair can they refer to a specific
part. So why is the vendor field hard-coded rather than factored
with this?
Anyway, it's easily achieved with an extra predicate.
Andrew
2011-10-07 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/predicates.md (shift_amount_operand): Remove constant
range check.
(shift_operator): Check range of constants for all shift operators.
gcc/testsuite/
* gcc.dg
On 06/10/11 16:01, Andrew Stubbs wrote:
(define_special_predicate shift_operator
(and (ior (ior (and (match_code mult)
(match_test power_of_two_operand (XEXP (op, 1), mode)))
(and (match_code rotate)
(match_test GET_CODE (XEXP
it can different altrnatives, and
there's obscure rules about which one wins when both match.
OK, so we'd just need a shift_operator_that_isnt_mult predicate,
(probably not with that name).
Andrew
2011-10-07 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/predicates.md
after studying all this is that we don't need to do
anything until somebody reports an ICE, at which point it becomes worth
the effort of fixing it. Other opinions welcome! :)
Andrew
2011-10-06 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/predicates.md (shift_amount_operand
On Wed 05 Oct 2011 09:33:09 BST, Andreas Krebbel wrote:
Hi,
the optab_handler uses in expand_mult_highpart_optab haven't been
replaced with the widening_optab_handler yet.
Apologies, I don't know how I missed that one? :(
Andrew
it is. :)
I've also fixed the problem that if it didn't recognise the CPU, it
defaulted to the hard default, ignoring the --with-cpu configured default.
OK?
Andrew
2011-09-20 Andrew Stubbs a...@codesourcery.com
gcc/
* config.host (arm*-*-linux*): Add driver-arm.o and x-arm.
* config/arm
On 19/09/11 10:12, Paul Brook wrote:
In Thumb-2 mode we try and match an M constraint (const_int between 0 and
31) with no other alternatives. This fails, and with nowhere else to go we
ICE.
The fix is to restrict the predicate for these insns to only accept valid
const_int shift counts. This
On 08/09/11 16:32, Richard Earnshaw wrote:
OK.
Committed, thanks
Andrew
This patch fixes PR50318 in which the compiler fails with a bad gimple
expression.
The problem was caused by a cut-and-paste error. I don't understand why
it wasn't caught in testing, but it's fixed now.
Committed as obvious.
Andrew
2011-09-08 Andrew Stubbs a...@codesourcery.com
PR tree
for other implementers and CPU names in future.
It has been suggested that this patch should use auxv rather than
/proc/cpuinfo. Does anybody here have any insight/preferences?
Is the patch OK?
Andrew
2011-08-27 Andrew Stubbs a...@codesourcery.com
gcc/
* config.host (arm*-*-linux*): Add
On 01/09/11 17:21, Andrew Stubbs wrote:
I wasn't sure how to find the mode of shift operand in the predicate
though, so I've assumed they're always the same size. How would one find
the proper mode in a predicate?
OK, no reply, so I'm just going to assume we're dealing with 32-bit
registers
that the constant is
positive. I've confirmed that values larger than the mode-size are not a
problem because the compiler optimizes those away earlier, even at -O0.
OK?
Andrew
2011-09-01 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/predicates.md (shift_amount_operand): Ensure shift
On 01/09/11 14:21, Joseph S. Myers wrote:
On Thu, 1 Sep 2011, Andrew Stubbs wrote:
This patch fixes the problem by merely checking that the constant is positive.
I've confirmed that values larger than the mode-size are not a problem because
the compiler optimizes those away earlier, even
On 01/09/11 16:26, Andrew Stubbs wrote:
OK, fair enough, redundant or not, here's a patch with belt and braces.
OK now?
And again, with the patch
Andrew
2011-09-01 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/predicates.md (shift_amount_operand): Ensure shift
amount
On 01/09/11 16:51, Jakub Jelinek wrote:
IN_RANGE (INTVAL (op), 0, GET_MODE_PRECISION (mode) - 1) ?
Ok, I can make that change.
1) shift by 0 is well defined (though not sure if arm backend
supports it)
Yeah, I suppose I could allow 0, but I don't know why it would be
helpful? I mean,
On 26/08/11 11:03, Andrew Stubbs wrote:
There was a bug I found in final testing, so this has been delayed
somewhat.
I've just committed this version. There are a few minor changes to the
way negative/inverted constants are generated.
Bernd found another bug whist testing for arm. Apparently
On 30/08/11 15:32, Andrew Stubbs wrote:
On 26/08/11 11:03, Andrew Stubbs wrote:
There was a bug I found in final testing, so this has been delayed
somewhat.
I've just committed this version. There are a few minor changes to the
way negative/inverted constants are generated.
Bernd found
On 26/08/11 17:16, Joseph S. Myers wrote:
arm-tables.opt is a generated file. You need to modify the source files
and regenerate it, not modify the generated file.
Fixed; the native option value is now defined in arm.opt. Thanks for
spotting this.
OK?
Andrew
2011-08-27 Andrew Stubbs
-27 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm-cores.def (generic-armv7-a): New architecture.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm-tune.md: Regenerate.
* config/arm/arm.c (arm_file_start): Output .arch directive when
user passes -mcpu=generic
On 09/05/11 17:23, Andrew Stubbs wrote:
On 06/05/11 12:18, Richard Earnshaw wrote:
OK with a change to do that.
Thanks, I can't commit this until my ADDW/SUBW patch has been committed.
There was a bug I found in final testing, so this has been delayed somewhat.
I've just committed
this information listed
anywhere. I think there are a lot of clues in the kernel code, but it's
hard to mine and it mostly only goes as far the architecture version,
not the individual cpu. Any suggestions?
Otherwise, is this OK?
Andrew
2011-08-26 Andrew Stubbs a...@codesourcery.com
gcc
-a', but that will have to wait until it does
something meaningful.
OK?
Andrew
2011-08-26 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm-cores.def (generic-armv7-a): New architecture.
* config/arm/arm-tables.opt: Add generic-armv7-a tune/cpu type.
* config/arm/arm-tune.md: Regenerate
On 22/07/11 16:34, Andrew Stubbs wrote:
On 22/07/11 14:28, Bernd Schmidt wrote:
Oh well, let's shelve it and do it later.
Here's an updated patch with the formatting problem you found fixed.
I've just committed an updated version of this patch (attached).
I found a number of subtle bugs
Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.md (maddhidi4): Remove '*' from name.
* expr.c (expand_expr_real_2): Use find_widening_optab_handler.
* optabs.c (find_widening_optab_handler_and_mode): New function.
(expand_widen_pattern_expr): Use find_widening_optab_handler
On 12/07/11 11:52, Richard Guenther wrote:
Is this one ok?
Ok.
I've just committed this slightly modified patch.
The changes are mainly in the context and the testcase.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen
On 14/07/11 15:25, Richard Guenther wrote:
Ok.
Committed, with no real changes. I just updated the testcase a little.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_mult_to_widen): Convert
unsupported unsigned multiplies to signed
On 14/07/11 15:31, Richard Guenther wrote:
Ok.
I've just committed this patch with no real changes. I've just updated
the testcase.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (is_widening_mult_p): Remove FIXME.
Ensure the the larger type
the new
version is a bit easier to understand in any case.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (is_widening_mult_rhs_p): Add new argument
'type'.
Use 'type' from caller, not inferred from 'rhs'.
Don't reject non-conversion statements. Do
On 19/08/11 15:45, Richard Guenther wrote:
Seems one in the series has broken bootstrap on x86_64 when building
the 32bit libgcc multilib in stage1.
Oh? Hopefully that'll be fixed when I complete the patchset. Patches 8
and 9 (of 7) did fix issues with the earlier patches.
Andrew
On 14/07/11 15:41, Richard Guenther wrote:
Ok.
Committed, unchanged apart from the test case.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_mult_to_widen): Better handle
unsigned inputs of different modes.
(convert_plusminus_to_widen
On 21/07/11 14:14, Andrew Stubbs wrote:
Here is the patch I plan to commit, when patch 1 is approved, and my
testing is complete.
Committed, unchanged.
Andrew
On 22/07/11 16:38, Andrew Stubbs wrote:
Fixed in the attached. I'll commit this version when the rest of my
testing is complete.
Now committed. Here's the patch with updated context.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (is_widening_mult_rhs_p
On 19/08/11 15:51, Andrew Stubbs wrote:
On 19/08/11 15:45, Richard Guenther wrote:
Seems one in the series has broken bootstrap on x86_64 when building
the 32bit libgcc multilib in stage1.
Oh? Hopefully that'll be fixed when I complete the patchset. Patches 8
and 9 (of 7) did fix issues
On 21/07/11 20:29, Joseph S. Myers wrote:
On Tue, 12 Jul 2011, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Arithmetic on such types is a perfectly reasonable notion to have in
On 21/07/11 14:22, Richard Guenther wrote:
On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbsa...@codesourcery.com wrote:
This patch is part bug fix, part better optimization.
Firstly, my initial patch series introduced a bug that caused an internal
compiler error when the input to a multiply was
ENOPATCH
On 22/07/11 12:57, Andrew Stubbs wrote:
On 21/07/11 14:22, Richard Guenther wrote:
On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbsa...@codesourcery.com
wrote:
This patch is part bug fix, part better optimization.
Firstly, my initial patch series introduced a bug that caused
On 22/07/11 13:34, Bernd Schmidt wrote:
@@ -1242,7 +1242,8 @@ expand_binop_directly (enum machine_mode mode, optab
binoptab,
rtx target, int unsignedp, enum optab_methods methods,
rtx last)
{
- enum insn_code icode = optab_handler (binoptab, mode);
On 22/07/11 14:28, Bernd Schmidt wrote:
Oh well, let's shelve it and do it later.
Here's an updated patch with the formatting problem you found fixed.
OK?
Andrew
2011-07-22 Andrew Stubbs a...@codesourcery.com
gcc/
* expr.c (expand_expr_real_2): Use widening_optab_handler.
* genopinit.c
On 22/07/11 13:17, Richard Guenther wrote:
Ok.
I found a NULL-pointer dereference bug.
Fixed in the attached. I'll commit this version when the rest of my
testing is complete.
Thanks
Andrew
2011-07-22 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c
. This also required
inserting new SSA_NAMEs to make it work.
In order to insert the new SSA_NAME, I've simply reused the existing
type conversion code - the only difference is that the conversion may be
a no-op, so it just generates a straight forward assignment.
OK?
Andrew
2011-07-21 Andrew
not affect the addition
operation. That said, it really ought to remain correct or else bad
things could happen in later optimizations
Here is the patch I plan to commit, when patch 1 is approved, and my
testing is complete.
Andrew
2011-07-21 Andrew Stubbs a...@codesourcery.com
gcc
On 19/07/11 00:33, Janis Johnson wrote:
On 07/14/2011 07:16 AM, Andrew Stubbs wrote:
{ dg-options -O2 -march=armv7-a }
The tests use { dg-options -O2 -march=armv7-a } but -march will be
overridden for multilibs that specify -march, and might conflict with
other multilib options. If you
series, but I've already regenerated the whole lot several times, it's
getting confusing, and they're all approved already, so I'm just going
to tack this one on the end.
Andrew
2011-07-18 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Convert
This update changes only the context modified by changes to patch 2. The
patch has already been approved. I'm just posting it for completeness.
Andrew
2011-07-14 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion
I've updated this patch following the changes earlier in the patch
series. There isn't much left.
This should obviate all the review comments. :)
OK?
Andrew
2011-07-14 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (is_widening_mult_p): Remove FIXME.
Ensure
not come from an assign statement (this can happen when the value comes
from a function parameter).
This patch fixes that case, and updates the context changed by my
updates earlier in the patch series.
OK?
Andrew
2011-07-14 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math
On 28/06/11 17:23, Andrew Stubbs wrote:
On 23/06/11 15:43, Andrew Stubbs wrote:
Patch 4 introduced support for using signed multiplies to code unsigned
multiplies in a narrower mode. Patch 5 then introduced support for
mis-matched input modes.
These two combined mean that there is case where
Ping. This is the last unreviewed patch in this series ...
Thanks
Andrew
On 09/07/11 15:43, Andrew Stubbs wrote:
On 23/06/11 15:37, Andrew Stubbs wrote:
This patch should have no effect on the compiler output. It merely
replaces one way to represent widening operations with another
On 23/06/11 15:39, Andrew Stubbs wrote:
This patch has two effects:
1. It permits the use of widening multiply instructions that widen by
more than one mode. E.g. HImode - DImode.
2. It enables the use of widening multiply instructions for (extended)
inputs of narrower mode than
On 12/07/11 11:35, Georg-Johann Lay wrote:
+(define_insn *mulsu
+ [(set (match_operand:HI 0 register_operand =r)
+(mult:HI (sign_extend:HI (match_operand:QI 1 register_operand a))
+ (zero_extend:HI (match_operand:QI 2 register_operand
a]
+
On 12/07/11 12:05, Richard Guenther wrote:
(**) We really ought to forbid any arithmetic on types that have non-mode
precision and only allow conversions to/from such types.
Hmmm, presumably the problem is that we might have a compatible
precision, but the backends actually work with purely
to be careful about casting unsigned
variables whenever they expect purely unsigned math. :(
Is this one ok?
Andrew
2011-07-11 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion statement separating multiply
On 23/06/11 15:37, Andrew Stubbs wrote:
This patch should have no effect on the compiler output. It merely
replaces one way to represent widening operations with another, and
refactors the other parts of the compiler to match. The rest of the
patch set uses this new framework to implement
On 07/07/11 13:37, Richard Guenther wrote:
I'll cook up a quick patch for VRP.
Like the attached. I'll finish and properly test it.
Your patch appears to do the wrong thing for this test case:
int
foo (int a, short b, short c)
{
int bc = b * c;
return a + (short)bc;
}
With your patch,
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings, (int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Hmm, I'm not so sure. I'll look into it a bit further.
+/*
On 07/07/11 11:04, Richard Guenther wrote:
Both types are equal, so please share the temporary variable you
create
+ rhs1 = build_and_insert_cast (gsi, gimple_location (stmt),
+ create_tmp_var (type1, NULL),
rhs1, type1);
+ rhs2 =
On 07/07/11 11:26, Andrew Stubbs wrote:
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings,
(int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Hmm, I'm not so sure
sequences can
exist? Is this necessary? I haven't managed to coax it to generated any
examples of extends followed by truncates myself, but in any case, it's
hardly any code and it'll make sure it's future proofed.
OK?
Andrew
2011-06-28 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math
On 28/06/11 15:14, Andrew Stubbs wrote:
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively
On 28/06/11 16:08, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
This patch removes the restriction that the inputs to a widening
multiply must be of the same mode.
It does this by extending the smaller of the two inputs to match the
larger; therefore, it remains the case
On 28/06/11 16:30, Andrew Stubbs wrote:
On 23/06/11 15:42, Andrew Stubbs wrote:
This patch fixes the case where widening multiply-and-accumulate were
not recognised because the multiplication itself is not actually
widening.
This can happen when you have DI + SI * SI - the multiplication
.
I've also changed the test cases to address Janis' comments.
Andrew
2011-06-28 Andrew Stubbs a...@codesourcery.com
gcc/
* gimple.h (tree_ssa_harmless_type_conversion): New prototype.
(tree_ssa_strip_harmless_type_conversions): New prototype.
(harmless_type_conversion_p): New prototype
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively.
That works fine, but only if the target supports those operations
directly. Otherwise
On 28/06/11 13:33, Andrew Stubbs wrote:
On 23/06/11 15:41, Andrew Stubbs wrote:
If one or both of the inputs to a widening multiply are of unsigned type
then the compiler will attempt to use usmul_widen_optab or
umul_widen_optab, respectively.
That works fine, but only if the target supports
801 - 900 of 937 matches
Mail list logo
