maddsidi4 detection
Hi,
I'm trying to define the standard pattern maddsidi4. To do this I wrote this in
my backend (gcc4.5.2) :
(define_insn "maddsidi4"
[(set (match_operand:DI 0 "register_operand" "=a")
(plus:DI
(mult:DI
(sign_extend:DI (match_operand:SI 1 "general_operand" "%g"))
(sign_extend:DI (match_operand:SI 2 "nonimmediate_operand" "rm")))
(match_operand:DI 3 "register_operand" " 0")))]
""
"mulacc %2,%1,%0";
)
('a' constraints is for accumulator registers)
(the movdi standard pattern defines the moves from and to accumulator registers)
When I compile the following code, mulacc is properly emitted :
void test_maddsidi4(int a, int b, long long * c)
{
*c += (long long)a*(long long)b;
}
But when I write the following code, (mulsidi3 + adddi3) is chosen instead of
maddsi4:
void maddsidi4_alt(int a, int b, long long * c)
{
*c = (long long)a*(long long)b + (*c);
}
I tried in debug mode to figure out why maddsi4 is ignore in the last case. I
found in expr.c file, in 'expand_expr_real_2' function and in 'PLUS_EXPR'
switch case that instead of encountering a MULT_EXPR following the PLUS_EXPR,
an INDIRECT_REF is encountered. This seems quite logical given the '+(*c)' in
my test.
I'm quite surprised that the multiplication/addition detection is so
restrictive. Is there a way to enhance the mul/add detection without patching
expr.c ? Someone else has certainly met the same problem :) Feel free to send
me the trick or patch :)
Regards,
Selim
[pph] Merge from trunk rev 180687. Fix for skipped line tables
This merge was quite convoluted. It brought in the new macro
location features which required several changes in the line
table routines.
With it, I fixed the bug I had introduced with the PPH skipping
that left holes in the line map table. Instead of saving
absolute index numbers for the includer fields, we now write
relative indices. These are later relocated during read. This
way, it doesn't matter where individual line tables are inserted
(patch below).
Tested on x86_64. Committed to branch.
2011-11-22 Diego Novillo
* pph-streamer-in.c (pph_in_int): New.
(pph_in_line_map_ordinary): New.
(pph_in_line_map): Call it.
(pph_in_line_table_and_includes): Re-write to account for
new macro location changes.
(pph_prepend_to_chain): Fix warnings.
* pph-streamer-out.c (pph_out_int): New.
(pph_out_line_map_ordinary): New.
(pph_out_line_map): Call it.
(pph_out_line_table_and_includes): Re-write to account for
new macro location changes.
(pph_out_location): Likewise.
* pph.c (pph_file_change_handler): Likewise.
Index: cp/pph-streamer-in.c
===
--- cp/pph-streamer-in.c(revision 181521)
+++ cp/pph-streamer-in.c(working copy)
@@ -148,6 +148,17 @@ pph_in_hwi (pph_stream *stream)
}
+/* Read an int from STREAM. */
+
+static inline int
+pph_in_int (pph_stream *stream)
+{
+ HOST_WIDE_INT n = streamer_read_hwi (stream->encoder.r.ib);
+ gcc_assert (n == (int) n);
+ return (int) n;
+}
+
+
/* Read an unsigned HOST_WIDE_INT from STREAM. */
static inline unsigned HOST_WIDE_INT
@@ -243,26 +254,44 @@ pph_in_linetable_marker (pph_stream *str
}
+
+/* Read all the fields of struct line_map LM from STREAM. LM is assumed
+ to be an ordinary line map. */
+
+static void
+pph_in_line_map_ordinary (pph_stream *stream, struct line_map *lm)
+{
+ struct bitpack_d bp;
+
+ ORDINARY_MAP_FILE_NAME (lm) = pph_in_string (stream);
+ ORDINARY_MAP_STARTING_LINE_NUMBER (lm) = pph_in_linenum_type (stream);
+
+ /* Note that this index is an offset indicating the distance from LM
+ to the line map entry for LM's includer. It needs to be adjusted
+ while reading the line table in pph_in_line_table_and_includes. */
+ ORDINARY_MAP_INCLUDER_FILE_INDEX (lm) = pph_in_int (stream);
+ bp = pph_in_bitpack (stream);
+ ORDINARY_MAP_IN_SYSTEM_HEADER_P (lm)
+ = (unsigned char) bp_unpack_value (&bp, CHAR_BIT);
+ ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (lm) = bp_unpack_value (&bp,
+COLUMN_BITS_BIT);
+}
+
+
/* Read a line_map from STREAM into LM. */
static void
pph_in_line_map (pph_stream *stream, struct line_map *lm)
{
- struct bitpack_d bp;
+ struct lto_input_block *ib = stream->encoder.r.ib;
- lm->to_file = pph_in_string (stream);
- lm->to_line = pph_in_linenum_type (stream);
lm->start_location = pph_in_source_location (stream);
- lm->included_from = (int) pph_in_uint (stream);
+ lm->reason = streamer_read_enum (ib, lc_reason, LC_ENTER_MACRO);
- bp = pph_in_bitpack (stream);
- lm->reason = (enum lc_reason) bp_unpack_value (&bp, LC_REASON_BIT);
- gcc_assert (lm->reason == LC_ENTER
- || lm->reason == LC_LEAVE
- || lm->reason == LC_RENAME
- || lm->reason == LC_RENAME_VERBATIM);
- lm->sysp = (unsigned char) bp_unpack_value (&bp, CHAR_BIT);
- lm->column_bits = bp_unpack_value (&bp, COLUMN_BITS_BIT);
+ /* FIXME pph. We currently do not support location tracking for
+ macros in PPH images. */
+ gcc_assert (lm->reason != LC_ENTER_MACRO);
+ pph_in_line_map_ordinary (stream, lm);
}
@@ -297,28 +326,30 @@ pph_in_include (pph_stream *stream)
}
-/* Read the line_table from STREAM and merge it in the current line_table. At
- the same time load includes in the order they were originally included by
- loading them at the point they were referenced in the line_table.
-
- Returns the source_location of line 1 / col 0 for this include.
+/* Read the line_table from STREAM and merge it in the current
+ line_table. At the same time load includes in the order they were
+ originally included by loading them at the point they were
+ referenced in the line_table.
- FIXME pph: The line_table is now identical to the non-pph line_table, the
- only problem is that we load line_table entries twice for headers that are
- re-included and are #ifdef guarded; thus shouldn't be replayed. This is
- a known current issue, so I didn't bother working around it here for now.
*/
+ Returns the source_location of line 1 / col 0 for this include. */
static source_location
pph_in_line_table_and_includes (pph_stream *stream)
{
- unsigned int old_depth;
+ unsigned int used_before, old_depth;
bool first;
- int includer_ix = -1;
- unsigned int used_before = line_table->used;
- int entries_offset = line_
gcc register allocation error when reloading an asm
Hello colleagues,
I've come across a suspicious error with inline asm and register allocation,
and am looking for a clarification of the rules.
What aspect of inline asm processing is preventing gcc from allocating
register eax to both %0 and %1's address in the following test case?
gcc -m32 -S foo.c
foo.c: In function 'foo':
foo.c:20: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
I could understand this error if val was an early clobber, "=&r" (val),
as the description of "&" says such operands cannot be assigned to the
same register as an input, or any register used in a memory address.
But since no ampersand is present, it seems eax is available here
for both operands.
int foo(int *ptr) {
int val;
__asm__ __volatile__("junk %0, %1"
: "=r" (val), "+m" (*ptr)
: : "memory" , "ebx" , "ecx" , "edx" , "esi" , "edi");
return val;
}
Looking forward to an answer, thanks!
Mitch Bodart
Intel Corporation
Linking libgcc with xgcc fails in build of trunk
All, I'm trying to build trunk with C only on NetBSD 5.1. I've gotten to the point where libgcc is built with xgcc and I get a failure when linking libgcc_s.so with: /usr/bin/ld: /usr/local/lib: No such file: I replaced ld with echo to see the link line and /usr/local/lib is sent to the linker as a file. In $(BUILD)/gcc/spec is a section with the following: *link_libgcc: %D /usr/local/lib I tried removing this line, but the file is regenerated by the make system. Since others have built and are building trunk, I assume that I have a misconfiguration. I am using the same configuration options that successfully built gcc-4.6.2. Any help is appreciated. Aran
Re: gcc register allocation error when reloading an asm
On 11/22/2011 10:55 AM, Bodart, Mitch L wrote:
> What aspect of inline asm processing is preventing gcc from allocating
> register eax to both %0 and %1's address in the following test case?
>
> gcc -m32 -S foo.c
> foo.c: In function 'foo':
> foo.c:20: error: can't find a register in class 'GENERAL_REGS' while
> reloading 'asm'
>
> I could understand this error if val was an early clobber, "=&r" (val),
> as the description of "&" says such operands cannot be assigned to the
> same register as an input, or any register used in a memory address.
> But since no ampersand is present, it seems eax is available here
> for both operands.
>
> int foo(int *ptr) {
> int val;
>
> __asm__ __volatile__("junk %0, %1"
> : "=r" (val), "+m" (*ptr)
%1 is also an output operand (+), which means its address needs to be
available as an output address reload. This will conflict with normal
output reloads.
I think I know what you are trying to write: %1 as a RW memory, but
the address is latched on input; %0 as an independent output.
You could try writing this as
: "=r"(val), "=X"(*ptr) : "m"(*ptr)
instead. Untested, so there might be other gotchas...
r~
Re: Linking libgcc with xgcc fails in build of trunk
Generally questions about building or using gcc should go to the gcc-help mailing list, not here. On 22 November 2011 19:01, Aran Clauson wrote: > I tried removing this line, but the file is regenerated by the make system. > Since others have built and are building trunk, I assume that I have a > misconfiguration. I am using the same configuration options that successfully > built gcc-4.6.2. Any help is appreciated. It would help to provide those config options. Have you seen http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51006 ? Apart from that issue I had no problem building on NetBSD 5.1
RE: gcc register allocation error when reloading an asm
Thanks for the quick response Richard!
Unfortunately the source change suggestion didn't work, but that's OK because I
can make the asm work by eliminating some register pressure.
Bottom line is I was looking to find out if there was a compiler problem under
the hood.
Sounds like the answer is no, or atleast, nothing that's going to be fixed
anytime soon.
thanks again!
Mitch
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 22, 2011 11:35 AM
> To: Bodart, Mitch L
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc register allocation error when reloading an asm
>
> On 11/22/2011 10:55 AM, Bodart, Mitch L wrote:
> > What aspect of inline asm processing is preventing gcc from allocating
> > register eax to both %0 and %1's address in the following test case?
> >
> > gcc -m32 -S foo.c
> > foo.c: In function 'foo':
> > foo.c:20: error: can't find a register in class 'GENERAL_REGS'
> while reloading 'asm'
> >
> > I could understand this error if val was an early clobber, "=&r"
> (val),
> > as the description of "&" says such operands cannot be assigned to the
> > same register as an input, or any register used in a memory address.
> > But since no ampersand is present, it seems eax is available here
> > for both operands.
> >
> > int foo(int *ptr) {
> > int val;
> >
> > __asm__ __volatile__("junk %0, %1"
> > : "=r" (val), "+m" (*ptr)
>
> %1 is also an output operand (+), which means its address needs to be
> available as an output address reload. This will conflict with normal
> output reloads.
>
> I think I know what you are trying to write: %1 as a RW memory, but
> the address is latched on input; %0 as an independent output.
>
> You could try writing this as
>
> : "=r"(val), "=X"(*ptr) : "m"(*ptr)
>
> instead. Untested, so there might be other gotchas...
>
>
> r~
Re: gcc register allocation error when reloading an asm
On 11/22/2011 12:11 PM, Bodart, Mitch L wrote: > Unfortunately the source change suggestion didn't work, but that's OK because > I can make the asm work by eliminating some register pressure. Hmm. Well, if you keep that "memory" clobber there, you don't actually need to represent the RW memory as an output at all -- we're indicating that all memory is changed. Try just "=r"(out) : "m"(*ptr) and see if that works. Otherwise... well, you've got your register pressure reduction. r~
gcc-4.4-20111122 is now available
Snapshot gcc-4.4-2022 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-2022/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 181641 You'll find: gcc-4.4-20111122.tar.bz2 Complete GCC MD5=7ec9c4515590068c0a40e71cdd03a52e SHA1=fe10254fdcf97aa3ee6ea5096ac87ff7a558f811 Diffs from 4.4-2015 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
success building gcc-4.6.2 on x86_64-apple-darwin11.2.0
The configure string was:
sh ../gcc-4.6.2/configure --enable-cloog-backend=isl
--program-suffix=4.6.2-g --enable-lto --enable-werror
--with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local
--with-ppl=/usr/local --enable-cloog-backend=isl --prefix=/usr/local
--enable-static=all --enable-libada
--enable-languages=c,c++,fortran,lto,objc
uname is:
Darwin moon 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00
PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
I was unable to build the boehm garbage collection. There is a patch here:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01104.html
which doesn't seem to be applied as of gcc-4.6.2. The other thing is,
there's a peculiarity with Darwin (or so people told me on freenode
#gcc) whereby the build would break because the configure scripts use
-V and -qversion and "that's been gone since 4.6". So after manually
removing instances of -V and -qversion from the configure scripts,
opting not for the boehm garbage collection, it compiled for c, c++,
fortran, lto, and objc. I couldn't get Java to compile.
Seems like the above patch is available, but has not been applied to
the trunk. Seems also that the -V and -qversion flags should probably
be ditched too.
Oh, one last thing, the environment had to be set correctly. I had
mpc, mpfr, and gmp in /usr/local, and the following environment
variables needed to be set for the compile to work:
ABI=64
CONFIG_SHELL=sh (NOT! bash)
ARCH=x86-64
CFLAGS="-m64 ${ARCH}"
DYLD_LIBRARY_PATH=/usr/local/lib
CC=gcc
I fear it's a bit of cargo cultery with the environment variables
(CC=gcc??), but it just seemed to work better that way.
Thanks for all your hard work putting the collection together. I
really appreciate it.
Oh, and if needs be, I have several x32 and x64 macs I can test things on.
--
Alex J Avriette
http://search.cpan.org/~alex/
http://www.linkedin.com/in/avriette (+1 858 3677293)
GCC 4.6 is inserting unnecessary MOVAPS instructions for SSE intrinsics
Hi, I have been hand optimising a loop that GCC 4.6 was not able to vectorise. I have been keeping an eye on the assembly output of this loop and have noticed GCC inserting unnecessary MOVAPS instructions. It only happens when I use the same variable for both inputs to a SSE intrinsic. E.g: __xmm128 input = /* something */; _mm_shuffle_ps(input, input, _MM_SHUFFLE(2, 3, 0, 1)); Will produce instructions like this: movaps %xmm0,%xmm1 shufps $0xb1,%xmm0,%xmm1 Where optimally it should be: shufps $0xb1,%xmm0,%xmm0 It appears that as _mm_shuffle_ps is a function it is treating the two inputs separately rather than combining them when they reference the same register. I have looked at Visual C++ 2010 and it does not add these extra MOVAPS instructions. It is likely that this does not have a large impact in performance as the CPU should just rename the registers, but it does add more instructions to decode and more stuff to place into instruction cache etc. The output of gcc -v Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6.2/configure --program-suffix=-4.6 --enable-threads --enable-languages=c,c++ --enable-linker-build-id Thread model: posix gcc version 4.6.2 (GCC) I am running 64 bit Ubuntu 10.10 so I compiled my own gcc 4.6 from source. The flags I used to compile: -O3 -march=native -ffast-math -fbuiltin -g on a Intel Core 2 Duo. Thanks, Leith Bade le...@leithalweapon.geek.nz
Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)
On 22 November 2011 07:58, Eric Botcazou wrote: >> On cygwin, current gcc trunk, I get this new problem: >> >> /usr/local/src/trunk/objdir.withada/./gcc/xgcc >> -B/usr/local/src/trunk/objdir.withada/./gcc/ >> -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem >> /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include >> -c -g -O2 -W -Wall -gnatpg -nostdinc s-taprop.adb -o s-taprop.o >> s-tpoaal.adb:60:13: "Specific" is undefined (more references follow) >> make[5]: *** [s-taprop.o] Error 1 >> make[5]: Leaving directory > > Looks like the same problem, see gcc/ada/Makefile.in line 1573. certainly, looking at your commit r181573 and tranforming that into this situation... I myself can't parse that clause so I tried simply removing the '32' out of cygwin32 but then I hit into something else... /usr/local/src/trunk/objdir.withada/./gcc/xgcc -B/usr/local/src/trunk/objdir.withada/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -c -g -O2-W -Wall -gnatpg -nostdinc g-socthi.adb -o g-socthi.o g-socthi.adb:615:15: "WSASYSNOTREADY" is undefined g-socthi.adb:616:15: "WSAVERNOTSUPPORTED" is undefined g-socthi.adb:618:15: "WSANOTINITIALISED" is undefined g-socthi.adb:620:15: "WSAEDISCON" is undefined g-socthi.adb:627:15: duplication of choice value at line 575 make[6]: *** [g-socthi.o] Error 1 make[6]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada/rts' make[5]: *** [gnatlib] Error 2 make[5]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada' make[4]: *** [gnatlib-shared-win32] Error 2 make[4]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir.withada/i686-pc-cygwin/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir.withada' make: *** [all] Error 2 and that is beyond my grasp, there is something odd when cygwin is to use, I guess, mingw variants of files... -- Cheers, /ChJ
Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)
> /usr/local/src/trunk/objdir.withada/./gcc/xgcc > -B/usr/local/src/trunk/objdir.withada/./gcc/ > -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem > /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include > -c -g -O2-W -Wall -gnatpg -nostdinc g-socthi.adb -o g-socthi.o > g-socthi.adb:615:15: "WSASYSNOTREADY" is undefined > g-socthi.adb:616:15: "WSAVERNOTSUPPORTED" is undefined > g-socthi.adb:618:15: "WSANOTINITIALISED" is undefined > g-socthi.adb:620:15: "WSAEDISCON" is undefined > g-socthi.adb:627:15: duplication of choice value at line 575 > make[6]: *** [g-socthi.o] Error 1 > make[6]: Leaving directory > `/usr/local/src/trunk/objdir.withada/gcc/ada/rts' make[5]: *** [gnatlib] > Error 2 > make[5]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada' > make[4]: *** [gnatlib-shared-win32] Error 2 > make[4]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada' > make[3]: *** [gnatlib-shared] Error 2 > make[3]: Leaving directory `/usr/local/src/trunk/objdir.withada/gcc/ada' > make[2]: *** [gnatlib-shared] Error 2 > make[2]: Leaving directory > `/usr/local/src/trunk/objdir.withada/i686-pc-cygwin/libada' > make[1]: *** [all-target-libada] Error 2 > make[1]: Leaving directory `/usr/local/src/trunk/objdir.withada' > make: *** [all] Error 2 > > and that is beyond my grasp, there is something odd when cygwin is to > use, I guess, mingw variants of files... But grep is your friend. See s-oscons-tmplt.c lines 1343 and below. -- Eric Botcazou
Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)
> But grep is your friend. See s-oscons-tmplt.c lines 1343 and below. phew, beyond my abilities yet again. someone more cygwin knowledgable would need to look into that I suppose... -- Cheers, /ChJ
