Ping.
On 05/11/14 21:45, Andrew Stubbs wrote:
This patch adds the following warning message:
undefined.c:9:20: warning: statement may be undefined in the final loop
iteration. [-Waggressive-loop-optimizations]
for (i = 0; array[i] i 5; i++)
^
(Where the code ought
On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval.
Ping, Richard.
Ping.
On 13/11/14 21:35, Andrew Stubbs wrote:
On 12/11/14 11:15, Richard Biener wrote:
Please find a better way to communicate possibly_undefined_stmt than
enlarging struct loop. Like associating it with the niter bound
we record (so you can also have more than one).
Unfortunately, the bounds get
On 19/11/14 16:39, Marek Polacek wrote:
On Wed, Nov 19, 2014 at 04:32:43PM +, Andrew Stubbs wrote:
+if (warning_at (gimple_location (elt-stmt),
+OPT_Waggressive_loop_optimizations,
+Loop exit may
problem_stmts != vNULL)
+{
!problem_stmts.empty ()
Otherwise it looks ok.
I've committed the attached. I'll work up a patch to dedup the condition
shortly.
Andrew
2014-11-20 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Warn
On 14/11/14 11:12, Andrew Stubbs wrote:
On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval
On 27/11/14 17:05, Mike Stump wrote:
Could you include a link or the patch. If the test suite, I'll review it if no
one else steps up.
The original patch is here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01119.html
Thanks
Andrew
On 15/10/14 17:34, Jiong Wang wrote:
On 23/09/14 16:22, Stubbs, Andrew wrote:
Maybe the original patch is better? Or maybe it should reconfigure the
FPU instead of erroring out? But reconfigure it to what?
Andrew,
are you still working on this?
a bunch of tests on my local
-effective-target to test the default target, and then
adds options that would change the result of that test; it can cause a
test to get skipped when actually it would work fine. Anyway, that's a
problem for a different day.
OK to commit?
Andrew
2014-10-30 Andrew Stubbs a...@codesourcery.com
On 30/10/14 18:37, Mike Stump wrote:
On Oct 30, 2014, at 10:25 AM, Andrew Stubbs a...@codesourcery.com
wrote:
Many of the tests in gcc.target/powerpc specify an explicit -mcpu
option with dg-options.
So, I think this isn’t the strategy people like for this sort of
thing. The problem
On 03/11/14 18:36, Mike Stump wrote:
On Oct 30, 2014, at 10:25 AM, Andrew Stubbs a...@codesourcery.com wrote:
Many of the tests in gcc.target/powerpc specify an explicit -mcpu option with
dg-options. This is a problem for multilib configurations that use -mcpu in
their definition
OK
optimization. Would it be appropriate
to do so?
OK to commit?
Andrew
2014-11-05 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Set
loop-possibly_undefined_stmt appropriately.
* tree-ssa-loop-ivcanon.c (remove_redundant_iv_tests): Warn if
any
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval.
Ping, Richard.
Andrew
-mfpu=neon at face value, regardless of -march or -mcpu.
This patch limits NEON to armv7 or higher.
OK?
Andrew
2014-09-13 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.h (TARGET_NEON): Ensure target is v7 or higher.
Index: gcc/config/arm/arm.h
On 15/09/14 10:46, Richard Earnshaw wrote:
Hmm, I wonder if arm_override_options should reject neon + (arch 7).
Is this more to your taste?
Andrew
P.S. arm_override_options was renamed in 2010.
2014-09-15 Andrew Stubbs a...@codesourcery.com
* gcc/config/arm/arm.c (arm_option_override
On 15/09/14 14:29, Richard Earnshaw wrote:
Yep, that's fine.
Committed, thanks.
Andrew
On 14/03/11 17:10, Richard Earnshaw wrote:
Finally, alternatives from an insn are normally selected left-to-right
from those available in a pattern, all other things being equal. So
really the A8-only alternative should come after the core registers
alternatives if its less preferable.
OK, I
On 14/03/11 18:17, Richard Earnshaw wrote:
I think the order should be: not-a8, core-regs, core-regs, only-a8.
Ok, how about this?
I've tested that it still builds spec2k crafty.
Andrew
On 24/03/11 13:22, Richard Earnshaw wrote:
OK
Committed, thanks.
Andrew
On 30/03/11 16:13, Richard Earnshaw wrote:
2011-02-14 Andrew Stubbsa...@codesourcery.com
Julian Brownjul...@codesourcery.com
Mark Shinwellshinw...@codesourcery.com
gcc/
* config/arm/arm.h (arm_class_likely_spilled_p): Check against
LO_REGS
[Ignoring the other issues for now ...]
On 12/04/11 11:02, Richard Earnshaw wrote:
Also, your change to use a double-letter sequence beginning with 'j'
means any hand-written inline assembly code using a single 'j' will
break (that's a backwards compatibility issue for users); is there
really
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
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
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
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 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
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
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
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 \
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
On 05/04/12 05:43, Michael Hope wrote:
Andrew, could you check that the Google guys have the final version of
your patch?
Yes, it looks fine to me.
Could you backport the fix to the 4.6 release branch if valid? Better
than having the same patch in three places.
Ok, I'll need permission
Ping.
On 30/03/12 12:15, Andrew Stubbs wrote:
On 28/02/12 16:20, Andrew Stubbs wrote:
Hi all,
This patch implements 64-bit immediate constant loads in NEON.
The current state is that you can load const_vector, but not const_int.
This is clearly not ideal. The result is a constant pool entry
Ping.
On 26/03/12 11:14, Andrew Stubbs wrote:
On 28/02/12 17:45, Andrew Stubbs wrote:
Hi all,
This patch adds a DImode negate pattern for NEON.
Unfortunately, the NEON vneg instruction only supports vectors, not
singletons, so there's no direct way to do it in DImode, and the
compiler ends
On 12/04/12 16:48, Richard Earnshaw wrote:
If negation in Neon needs a scratch register, it seems to me to be
somewhat odd that we're disparaging the ARM version.
Good point, I'm really meaning to provide missing functionality in NEON
to prevent unnecessary moves, rather than cause them, so I
On 12/04/12 16:48, Richard Earnshaw wrote:
If negation in Neon needs a scratch register, it seems to me to be
somewhat odd that we're disparaging the ARM version.
Also, wouldn't it be sensible to support a variant that was
early-clobber on operand 0, but loaded immediate zero into that value
And now with the patch. :(
On 14/04/12 13:48, Andrew Stubbs wrote:
On 12/04/12 16:48, Richard Earnshaw wrote:
If negation in Neon needs a scratch register, it seems to me to be
somewhat odd that we're disparaging the ARM version.
Also, wouldn't it be sensible to support a variant
, most of the passes do dumps by calling fprintf directly, and
I don't want to edit each and every case, so I've implemented this by
setting dump_file=NULL in execute_one_pass.
OK to commit?
Andrew
2012-04-18 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-pass.h (TDF_QUIET): New define
On 18/04/12 19:00, Xinliang David Li wrote:
Why only rtl? Minor suggestion: use ir or il may be more intuitive:
-fdump-rtl-all-ir
It isn't only RTL. It also applies to the tree dumps. I did say so in my
message, although all the examples were RTL.
Also, ir and il are not more intuitive to
On 18/04/12 22:09, Xinliang David Li wrote:
Flags in category 1)
--
There are four types of information that can be dumped (should be
controlled by flag set 1) ):
1.a) transformation decisions -- such as
-fdump-tree-vectorize-transformations (to be added)
1.b)
On 19/04/12 17:21, Xinliang David Li wrote:
To me, the existing (default), verbose, details option set makes sense,
and adding quiet to that set seemed appropriate. I'm not sure I like the
idea of renaming existing options, even if they aren't likely to break much.
It is confusing. 'verbose'
Ping.
On 10/04/12 14:00, Andrew Stubbs wrote:
Ping.
On 30/03/12 12:15, Andrew Stubbs wrote:
On 28/02/12 16:20, Andrew Stubbs wrote:
Hi all,
This patch implements 64-bit immediate constant loads in NEON.
The current state is that you can load const_vector, but not const_int.
This is clearly
On 27/04/12 16:17, Richard Earnshaw wrote:
This is OK.
Thanks, now committed.
It would be good to merge all the target32 movdi variants into one
pattern and then use alternative enabling to deal with the different
valid alternatives.
Yes, I'll take a look.
Andrew
On 16/04/12 13:41, Richard Earnshaw wrote:
P.S. This patch can't actually be committed until my NEON DImode
immediate constants patch is approved and committed. (Without that the
load #0 needs a constant pool, and loading constants this late has a bug
at -O0.)
neon-neg64.patch
2012-04-12
On 19/04/12 13:58, Andrew Stubbs wrote:
In the meantime, Mr Maintainers, can I commit my patch while we wait for
the new world order? I'm happy to change the option name quiet to
something else if necessary.
Ping.
I think David may have a point about 'quiet' being an inappropriate name
Ping.
On 02/05/12 10:49, Andrew Stubbs wrote:
On 19/04/12 13:58, Andrew Stubbs wrote:
In the meantime, Mr Maintainers, can I commit my patch while we wait for
the new world order? I'm happy to change the option name quiet to
something else if necessary.
Ping.
I think David may have a point
On 16/05/12 11:25, Ramana Radhakrishnan wrote:
Ok with those changes.
Hi Ramana,
Here's an update rebased and modified as requested.
Can you please confirm that the comments explain what you wanted to
know, and then I will commit it.
Thanks
Andrew
2012-05-16 Andrew Stubbs
On 16/05/12 17:43, Ramana Radhakrishnan wrote:
OK (if no regressions).
Cross tested with no regressions, and committed.
Thanks
Andrew
On 23/02/12 20:36, Andrew Stubbs wrote:
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
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the operands again, to
simply extract the existing operands, which have already been formulated
correctly for a widening multiply
On 17/08/12 15:31, Richard Earnshaw wrote:
On 17/08/12 15:22, Andrew Stubbs wrote:
On 17/08/12 15:04, Richard Earnshaw wrote:
The fix is to make is_widening_mult_p note that it has been called with
a WIDEN_MULT_EXPR and rather than decompose the operands again, to
simply extract the existing
On 17/08/12 15:47, Richard Earnshaw wrote:
If we don't have a 16x16-64 mult operation then after step 1 we'll
still have a MULT_EXPR, not a WIDEN_MULT_EXPR, so when we reach step2
there's nothing to short circuit.
Unless, of course, you're expecting us to get
step1 - 16x16-32 widen mult
step2
On 17/08/12 16:20, Richard Earnshaw wrote:
No, given a u16xu16-u64 operation in the code, and that the arch
doesn't have such an opcode, I'd expect to get
step1 - (u32)u16 x (u32)u16 - u64
Hmm, I would have thought that would be more costly than
(u64)(u16 x u16 - u32)
You might be
On 17/08/12 18:05, Richard Earnshaw wrote:
Take two.
This version should address your concerns about handling
(u32)u16 * (u32)u16 - u64
We now look at each operand directly, but when doing so we check whether
the operand is the same size as the result or not. When it is, we can
strip
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
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 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
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: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
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
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
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
. 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 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
On 26/10/11 10:15, Richard Earnshaw wrote:
Here's an updated patch that makes no generalizations.
OK?
Yep
Committed.
Andrew
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
Ping.
On 25/03/11 16:19, Andrew Stubbs wrote:
On 28/01/11 15:20, Richard Earnshaw wrote:
On Fri, 2011-01-28 at 15:13 +, Andrew Stubbs wrote:
On 28/01/11 14:12, Richard Earnshaw wrote:
So what happens to a variation of your testcase:
long long foolong (long long x, short *a, short *b
This patch removes some redundant code that caused me some confusion.
It's not possible to construct a constant from multiple ORN
instructions, just as it's not possible to do it with multiple AND
instructions.
OK?
Andrew
2011-04-20 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm
then.
OK?
Andrew
2011-04-20 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.c (arm_gen_constant): Move mowv support
(const_ok_for_op): ... to here.
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2461,6 +2461,13 @@ const_ok_for_op (HOST_WIDE_INT i, enum rtx_code code
for that coming soon.
This patch requires that my previously posted patch for MOVW is applied
first.
OK?
Andrew
2011-04-20 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm-protos.h (const_ok_for_op): Add prototype.
* config/arm/arm.c (const_ok_for_op): Add support for addw/subw.
Remove
On 20/04/11 16:27, Andrew Stubbs wrote:
(*arm_subsi3_insn): Add subw support.
Oh, I should probably say that I've added subw support to arm_subsi3
even though it's not obvious that anything will ever use this.
The existing implementation of arm_subsi3 (sans 'w') supports
immediates
, and committed a patch to fix this
yesterday.
In fact ORN is only of limited use for this kind of thing. Like AND, you
can't use multiple ORNs to build a constant. The compiler already does
use ORN in some circumstances, and this patch has not changed that.
Is the patch OK?
Andrew
2011-04-21 Andrew
On 21/04/11 16:58, Joseph S. Myers wrote:
You need to add
%inherit GCC_4.7.0 GCC_4.6.0
GCC_4.7.0 {
}
Ok, done. Is this OK now?
Andrew
2011-04-27 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.c (arm_init_libfuncs): Change __gnu_f2h_ieee to
__aeabi_f2h, __gnu_f2h_alternative
On 03/05/11 10:07, Bernd Schmidt wrote:
I tried to fix it with the patch below, which unfortunately doesn't work
since during combine we don't see the SIGN_EXTEND operations inside the
MULT, but two shift operations instead. Maybe you can complete it from here?
I'll take a look.
Thanks for
with this change.
OK with a change to do that.
Thanks, I can't commit this until my ADDW/SUBW patch has been committed.
Andrew
2011-05-09 Andrew Stubbs a...@codesourcery.com
gcc/
* config/arm/arm.c (struct four_ints): New type.
(count_insns_for_constant): Delete function.
(find_best_start
Ping.
On 20/04/11 16:27, Andrew Stubbs wrote:
This patch adds basic support for the Thumb ADDW and SUBW instructions.
The patch permits the compiler to use the new instructions for constants
that can be loaded with a single instruction (i.e. 16-bit unshifted),
but does not support use of addw
On 20/05/11 10:45, Dmitry Plotnikov wrote:
This patch adds support for 12-bit immediate values for Thumb-2 in ADD and
SUB instructions. We added two new alternatives for *arm_addsi3 which
make use of two new constraints for 12-bit values. Also we modified
costs of PLUS rtx expression.
A
patch).
It does assume that the outer sign_extend/zero_extend indicates the
inner extend types though, so I'm not sure if there's a problem there?
OK?
Andrew
2011-05-24 Bernd Schmidt ber...@codesourcery.com
Andrew Stubbs a...@codesourcery.com
gcc/
* simplify-rtx.c
On 24/05/11 20:35, Joseph S. Myers wrote:
On Tue, 24 May 2011, Andrew Stubbs wrote:
I've created this new, simpler patch that converts
(extend (mult a b))
into
(mult (extend a) (extend b))
regardless of what 'a' and 'b' might be. (These are then simplified and
superfluous extends
On 24/05/11 20:35, Joseph S. Myers wrote:
On Tue, 24 May 2011, Andrew Stubbs wrote:
I've created this new, simpler patch that converts
(extend (mult a b))
into
(mult (extend a) (extend b))
regardless of what 'a' and 'b' might be. (These are then simplified and
superfluous extends
On 25/05/11 14:19, Joseph S. Myers wrote:
RTL has defined abstract semantics and RTL transformations should be ones
that are valid in accordance with those semantics, with proper assertions
if there are additional constraints on the input passed to a function.
This means actually counting the
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
1 - 100 of 917 matches
Mail list logo
