Re: [RFC] Detect most integer overflows.
Hi!
On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> For a "quick" GCC implementation of the builtins you could expand
> them to a open-coded sequence during gimplification. But due to
> the issues pointed out above I'm not sure it is the best interface
> to support (though now the names are taken).
I played around with gcc internals for the first time today and came
up with this. As this is my first patch to gcc I am very happy to hear
feedback. Thanks!
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index fba9c7d..7d01c91 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -134,7 +134,10 @@ DEF_PRIMITIVE_TYPE (BT_I8, builtin_type_for_size
(BITS_PER_UNIT*8, 1))
DEF_PRIMITIVE_TYPE (BT_I16, builtin_type_for_size (BITS_PER_UNIT*16, 1))
DEF_POINTER_TYPE (BT_PTR_CONST_STRING, BT_CONST_STRING)
+DEF_POINTER_TYPE (BT_PTR_UINT, BT_UINT)
DEF_POINTER_TYPE (BT_PTR_LONG, BT_LONG)
+DEF_POINTER_TYPE (BT_PTR_ULONG, BT_ULONG)
+DEF_POINTER_TYPE (BT_PTR_LONGLONG, BT_LONGLONG)
DEF_POINTER_TYPE (BT_PTR_ULONGLONG, BT_ULONGLONG)
DEF_POINTER_TYPE (BT_PTR_PTR, BT_PTR)
@@ -431,6 +434,21 @@ DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I8_INT, BT_VOID,
BT_VOLATILE_PTR, BT_I8, BT
DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I16_INT, BT_VOID, BT_VOLATILE_PTR,
BT_I16, BT_INT)
DEF_FUNCTION_TYPE_3 (BT_FN_INT_PTRPTR_SIZE_SIZE, BT_INT, BT_PTR_PTR, BT_SIZE,
BT_SIZE)
+DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_INT_INT_PTR_INT, BT_BOOL, BT_INT, BT_INT,
+BT_INT_PTR)
+DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_LONG_LONG_PTR_LONG, BT_BOOL, BT_LONG, BT_LONG,
+BT_PTR_LONG)
+DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_LONGLONG_LONGLONG_PTR_LONGLONG, BT_BOOL,
+BT_LONGLONG, BT_LONGLONG, BT_PTR_LONGLONG)
+
+DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_UINT_UINT_PTR_UINT, BT_BOOL, BT_UINT, BT_UINT,
+BT_PTR_UINT)
+DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_ULONG_ULONG_PTR_ULONG, BT_BOOL, BT_ULONG,
BT_ULONG,
+BT_PTR_ULONG)
+DEF_FUNCTION_TYPE_3 (BT_FN_BOOL_ULONGLONG_ULONGLONG_PTR_ULONGLONG, BT_BOOL,
+BT_ULONGLONG, BT_ULONGLONG, BT_PTR_ULONGLONG)
+
+
DEF_FUNCTION_TYPE_4 (BT_FN_SIZE_CONST_PTR_SIZE_SIZE_FILEPTR,
BT_SIZE, BT_CONST_PTR, BT_SIZE, BT_SIZE, BT_FILEPTR)
DEF_FUNCTION_TYPE_4 (BT_FN_INT_STRING_SIZE_CONST_STRING_VALIST_ARG,
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 5a76ba3..c1f5609 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -853,6 +853,37 @@ DEF_GCC_BUILTIN (BUILT_IN_FILE, "FILE",
BT_FN_CONST_STRING, ATTR_NOTHROW_LEAF_LI
DEF_GCC_BUILTIN (BUILT_IN_FUNCTION, "FUNCTION", BT_FN_CONST_STRING,
ATTR_NOTHROW_LEAF_LIST)
DEF_GCC_BUILTIN (BUILT_IN_LINE, "LINE", BT_FN_INT, ATTR_NOTHROW_LEAF_LIST)
+/* overflow builtins. */
+DEF_GCC_BUILTIN (BUILT_IN_UADD_OVERFLOW, "uadd_overflow",
+BT_FN_BOOL_UINT_UINT_PTR_UINT, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_UADDL_OVERFLOW, "uaddl_overflow",
+BT_FN_BOOL_ULONG_ULONG_PTR_ULONG, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_UADDLL_OVERFLOW, "uaddll_overflow",
+BT_FN_BOOL_ULONGLONG_ULONGLONG_PTR_ULONGLONG,
+ATTR_NOTHROW_LEAF_LIST)
+
+DEF_GCC_BUILTIN (BUILT_IN_USUB_OVERFLOW, "usub_overflow",
+BT_FN_BOOL_UINT_UINT_PTR_UINT, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_USUBL_OVERFLOW, "usubl_overflow",
+BT_FN_BOOL_ULONG_ULONG_PTR_ULONG, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_USUBLL_OVERFLOW, "usubll_overflow",
+BT_FN_BOOL_ULONGLONG_ULONGLONG_PTR_ULONGLONG,
+ATTR_NOTHROW_LEAF_LIST)
+
+DEF_GCC_BUILTIN (BUILT_IN_SADD_OVERFLOW, "sadd_overflow",
+BT_FN_BOOL_INT_INT_PTR_INT, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_SADDL_OVERFLOW, "saddl_overflow",
+BT_FN_BOOL_LONG_LONG_PTR_LONG, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_SADDLL_OVERFLOW, "saddll_overflow",
+BT_FN_BOOL_LONGLONG_LONGLONG_PTR_LONGLONG,
ATTR_NOTHROW_LEAF_LIST)
+
+DEF_GCC_BUILTIN (BUILT_IN_SSUB_OVERFLOW, "ssub_overflow",
+BT_FN_BOOL_INT_INT_PTR_INT, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_SSUBL_OVERFLOW, "ssubl_overflow",
+BT_FN_BOOL_LONG_LONG_PTR_LONG, ATTR_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN (BUILT_IN_SSUBLL_OVERFLOW, "ssubll_overflow",
+BT_FN_BOOL_LONGLONG_LONGLONG_PTR_LONGLONG,
ATTR_NOTHROW_LEAF_LIST)
+
/* Synchronization Primitives. */
#include "sync-builtins.def"
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 7441784..b4494a0 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -2224,6 +2224,138 @@ maybe_fold_stmt (gimple_stmt_iterator *gsi)
return fold_stmt (gsi);
}
+/* Is this an overflow builtin? */
+
+static bool
+builtin_overflow_p(tree fndecl)
+{
+ if (!fndecl)
+return false;
+ else if (DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL)
+return false;
+ else
+switch (DECL_FUNCTION_CODE (
Re: Code emitted was bloated with no optimisation.
Umesh Kalappa writes: > Richard , > Pmode is defined HImode and private target is 16 bit where int ,short > and Pmode is defined HImode and long as SImode. > > Please do let me know if it requires more information on the target. In that case I suggest you compile with -da and compare the .expand dumps for the optimised and unoptimised code. If they both use the same bad sequence, see (a) which pass manages to optimise it and (b) figure out why the expand-time code is so bad. If the difference is already present at expand time then presumably something is going wrong earlier. Thanks, Richard
Re: Unable to match instruction pattern
pshor...@dataworx.com.au writes:
> Found it ...
>
> I had
>
> (define_expand "zero_extendhisi2"
> [
> (set (subreg:HI (match_operand:SI 0 "general_operand" "")0)
> (match_operand:HI 1 "general_operand" ""))
> (set (subreg:HI (match_dup 0)2)
> (const_int 0))
> ]
> ""
> ""
> )
FWIW, in general you shouldn't use subregs in expanders, but instead use
something like:
(define_expand "zero_extendhisi2"
[(set (match_operand:SI 0 "general_operand" "")
(zero_extend:SI (match_operand:HI 1 "general_operand" "")))]
""
{
emit_move_insn (gen_lowpart (HImode, operands[0]), operands[1]);
emit_move_insn (gen_highpart (HImode, operands[0]), const0_rtx);
DONE;
})
This allows MEMs to be simplified to smaller MEMs, which is preferable
to keeping them as SUBREGs. It also allows subregs of hard registers
to be simplified to simple REGs and handles constants correctly.
IMO SUBREGs of MEMs should go away. There's this strange convention
that (subreg (mem ...)) is treated as a register_operand before reload,
which is why:
if( !register_operand( operands[0], mode )
&& !register_operand( operands[1], mode ))
{
/* one of the operands must be in a register. */
operands[1] = copy_to_mode_reg (mode, operands[1]);
}
wouldn't trigger for a move between a constant and a subreg of a MEM.
OTOH, you should be better off not defining the zero_extendhisi2 at all,
since IIRC the target-independent optabs code would generate the same
sequence for you.
Thanks,
Richard
GCC 4.9.0 Status Report (2014-04-11)
Status == We have reached zero P1 regressions today (and < 100 important regressions) and the branches/gcc-4_9-branch has been created today and GCC 4.9.0-rc1 built and announced. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, I'd like to release 4.9.0 after Easter Monday, if any important issues are discovered and fixed, rc2 could be released during the next week. Please help testing this release. Quality Data Priority # Change from last report --- --- P10- 9 P2 76+ 1 P36- 9 --- --- Total82- 17 Previous Report === http://gcc.gnu.org/ml/gcc/2014-03/msg00190.html The next report will be sent by me again, hopefully announcing the 4.9.0 release.
GCC 4.10.0 Status Report (2014-04-11), Stage 1 starts now
Status == The trunk has branched for the GCC 4.9 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 4.9 so it is possible to test important fixes for 4.9.0 on it. As for the version, we are temporarily using 4.10 as version on the trunk, whether it will stay 4.10, be changed to 5.0 or whether we switch to some different release version numbering system is yet to be discussed, either at GNU Tools Cauldron 2014 or earlier. Would be nice if the first big merge to trunk was wide-int, but preferably only after 4.9.0 is released. Of course, smaller queued and already approved patches can be committed even before that. Quality Data Priority # Change from last report --- --- P10- 9 P2 76+ 1 P36- 9 --- --- Total82- 17 Previous Report === http://gcc.gnu.org/ml/gcc/2014-03/msg00190.html The next report will be sent by Joseph.
GCC 4.9.0 Release Candidate available from gcc.gnu.org
GCC 4.9.0 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.9.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.9.0-RC-20140411 and shortly its mirrors. It has been generated from SVN revision 209307. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.9.0 on Tuesday, 22nd.
Re: Code emitted was bloated with no optimisation.
Richard , Pmode is defined HImode and private target is 16 bit where int ,short and Pmode is defined HImode and long as SImode. Please do let me know if it requires more information on the target. Thank you ~Umesh On Fri, Apr 11, 2014 at 4:35 PM, Richard Sandiford wrote: > Andrew Haley writes: >> On 04/10/2014 04:12 PM, Umesh Kalappa wrote: >> >>> Please somebody from the group can share their thoughts and will be >>> appricate the same. >> >> But unoptimized code is expected to be large. Why do you expect >> otherwise? > > Sure, but this is a bit extreme. I don't see off-hand how a[i] > would generate a branch, for starters. > > But it's very hard to answer this kind of question for a private port. > How is Pmode defined? If it's a partial integer mode like PSImode, > is the problem that the arithmetic is being done in SImode? > > Thanks, > Richard >
Re: Code emitted was bloated with no optimisation.
Hi Andrew, Appreciate your reply here and yes unoptimized code is expected to be large ,but for the construct like a[i] the below generated code looks crazy to me . ld WA, 10 ld (_a+18), WA ; a[9] = 10; ld WA, (_i) ;code bloated here for a[i] ld IX, WA ld BC, 15 cal _C87C_shris ld IY, WA ld DE, WA ld HL, BC ld WA, IX add WA, IX ld DE, WA ld WA, DE ld BC, HL ld HL, 1 ld (SP+2), HL cmp WA,IX j lt,_.L2 ld DE, 0 ld (SP+2), DE .L2: ld DE, WA ld HL, BC ld BC, IY add BC, IY ld HL, BC ld WA, DE ld BC, HL ld DE, (SP+2) add DE, BC ld BC, DE ld HL, WA ld (SP+0), HL ld WA, 20 ld HL, (SP+0) ld (a+i), WA Anyidea why it so ?? Thank you in advance ~Umesh On Thu, Apr 10, 2014 at 8:54 PM, Andrew Haley wrote: > On 04/10/2014 04:12 PM, Umesh Kalappa wrote: > >> Please somebody from the group can share their thoughts and will be >> appricate the same. > > But unoptimized code is expected to be large. Why do you expect > otherwise? > > Andrew. >
gcc-4.10-20140411 is now available
Snapshot gcc-4.10-20140411 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140411/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 209307 You'll find: gcc-4.10-20140411.tar.bz2Complete GCC MD5=420b31ec5b2158374f986603d9744109 SHA1=5ee8a0433b93188a6e088f67b812c2ef02e131a8 Diffs from 4.10- are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [patch] Fix texinfo warnings for doc/gcc.texi [was: Re: doc bugs]
On Sat, Mar 29, 2014 at 10:51:58AM +0100, Tobias Burnus wrote: > 2014-03-29 Tobias Burnus > > PR other/59055 > * doc/bugreport.texi (Bugs): Remove nodes pointing to the > nirvana. > * doc/gcc.texi (Service): Update description in the @menu > * doc/invoke.texi (Option Summary): Remove misplaced and > duplicated @menu. Ok. Jakub
Re: Code emitted was bloated with no optimisation.
Andrew Haley writes: > On 04/10/2014 04:12 PM, Umesh Kalappa wrote: > >> Please somebody from the group can share their thoughts and will be >> appricate the same. > > But unoptimized code is expected to be large. Why do you expect > otherwise? Sure, but this is a bit extreme. I don't see off-hand how a[i] would generate a branch, for starters. But it's very hard to answer this kind of question for a private port. How is Pmode defined? If it's a partial integer mode like PSImode, is the problem that the arithmetic is being done in SImode? Thanks, Richard
