Re: why mult generated for unsigned int multiply on mips?
found the cause, sorry to disturb, please ignore this message. -- Best Regards.
Re: VTA/debugging vs reload-v2
On Apr 5, 2010, Jeff Law wrote: > On 04/05/10 14:32, Alexandre Oliva wrote: >> 2. When renaming references from P to P' in a region, do take debug >> insns in the region into account, renaming references in debug insns as >> you would in any other insn. > OK. So presumably the 2nd argument in a VAR_LOCATION can be any rtl > expression? Meaning I have to parse it looking for things that need > changing?Right? If DU can't help you get straight to them, yeah. > Or I might be able to get away with changing regno_reg_rtx to point to > the appropriate memref... +1 > Everything you noted seems to be designed to keep the existing > debug_insns updated -- under what circumstances are debug_insns > created (which ought to give me a clue about whether or not I'm going > to need to create new ones). You don't. debug insns are created out of debug stmts, created only at points in which a user variable changes values: at assignments and at confluences between possibly-different values (PHI nodes). There's no need to emit debug insns at loads or stores. Value tracking will realize, at the load and at the store, that the same value is in both operands at the end of the instruction, and will automatically issue debug notes as needed. ATM, the “as needed” is taken a bit too literally: only when a location for a variable or sub-expression dies is another location computed; some day we'll produce complete information, with *all* locations in which the value of a variable is stored. We may then have to be able to tell whether or not a location is shared with other variables, and if so, whether it's an LVALUE or RVALUE, so to speak, for each variable that refers to it. > FWIW, I don't see any references to debug_insn or var_location in > gcc/doc/*.texi. Somehow I think this must be unintentional. Indeed. Now that we're out of P1 VTA bugs for 4.5, I'll make it a priority to come up with something. Thanks! -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: GCC 4.5.0 release candidate available
On Tue, 6 Apr 2010, Jack Howarth wrote: > On Tue, Apr 06, 2010 at 03:45:27PM +0200, Richard Guenther wrote: > > > > A GCC 4.5.0 release candidate is available at: > > > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.0-RC-20100406/ > > > > Please test the tarballs and report any problems to Bugzilla. > > CC me on the bugs if you believe they are regressions from > > previous releases severe enough to block the 4.5.0 release. > > > > Thanks, > > Richard. > > > > -- > > Richard Guenther > > Novell / SUSE Labs > > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: > > Markus Rex > > > > Richard, >Any chance we can get r157822 reapplied on gcc 4.5 branch > along with... > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html > > to fix emutls? As can be seen from the testsuite run on > x86_64-apple-darwin10... > > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00444.html > > when all the "dg-require-effective-target tls_native" tests > are converted to "dg-require-effective-target tls", we only > see failures in... > > FAIL: gcc.dg/tls/opt-4.c scan-assembler tcc1@ > FAIL: gcc.dg/tls/opt-4.c scan-assembler tcc2@ > FAIL: gcc.dg/tls/opt-4.c scan-assembler-not tcc...@] > FAIL: gcc.dg/tls/opt-4.c scan-assembler-not tcc...@] > FAIL: gcc.dg/tls/section-1.c conflict with user-defined section (test for > errors, line 12) > > at -m32 and... > > FAIL: gcc.dg/tls/section-1.c conflict with user-defined section (test for > errors, line 12) > > at -m64. Iain thinks the gcc.dg/tls/opt-4.c failures are expected > but the gcc.dg/tls/section-1.c failure might be showing up a > previously unknown bug in emutls. Not before the 4.5.0 release. Richard.
compiler operations research
Hi, Are there any known methodologies/tools/flows that enable operations research on the compiler generated assembly? The reasoning behind the question is that compiler heuristics complexity are restricted by compilation time, while test environment can run for a long time taking into account both intermediate outputs of the different compilation stages and profiling of execution on real targets. The question does not relate to traditional profiler feedback techniques which are usually restricted for the positioning of code blocks/functions to minimize change of flow penalty but rather to the ISA utilization (whether the correct instruction is utilized in the correct places). Thanks, Roy.
Re: compiler operations research
On 07/04/2010 12:29, roy rosen wrote: > Hi, > > Are there any known methodologies/tools/flows that enable operations > research on the compiler generated assembly? Something like MILEPOST+ICI? An automated machine learning version of gcc: http://ctuning.org/wiki/index.php/CTools:MilepostGCC http://unidapt.org/index.php/Developments:ICI Might also be some interesting links at http://www.hipeac.net/tools cheers, DaveK
Re: compiler operations research
Thanks Dave, I'll have a look at these. Roy. 2010/4/7, Dave Korn : > On 07/04/2010 12:29, roy rosen wrote: > > Hi, > > > > Are there any known methodologies/tools/flows that enable operations > > research on the compiler generated assembly? > > Something like MILEPOST+ICI? An automated machine learning version of gcc: > > http://ctuning.org/wiki/index.php/CTools:MilepostGCC > http://unidapt.org/index.php/Developments:ICI > > Might also be some interesting links at > > http://www.hipeac.net/tools > >cheers, > DaveK >
RFC: merging GUPC into the GCC trunk?
Now that GCC 4.5 has been branched from the main line, it seems that this is an appropriate time to consider GUPC for inclusion into the GCC trunk. GUPC was recently checked in as a GCC branch: http://gcc.gnu.org/projects/gupc.html What is the recommended process for having GUPC reviewed (and hopefully, subsequently approved) for being merged into the GCC mainline? Thanks, - Gary
Re: RFC: merging GUPC into the GCC trunk?
On Wed, Apr 7, 2010 at 11:05, Gary Funck wrote: > What is the recommended process for having GUPC reviewed > (and hopefully, subsequently approved) for being merged > into the GCC mainline? I would suggest splitting patches across reviewer domains. See previous merges from big branches for examples. This makes it easier for maintainers and reviewers to review the relevant parts. Additionally, make sure that the branch bootstraps and tests on all primary/secondary platforms with all languages enabled. I can help reviewing patches in my areas. Please CC me, so it lands on my Inbox. Presumably, all the other requirements are met? (copyright paperwork, etc). Diego.
GCC primary/secondary platforms?
On 04/07/10 11:11:05, Diego Novillo wrote: > I would suggest splitting patches across reviewer domains. See > previous merges from big branches for examples. This makes it easier > for maintainers and reviewers to review the relevant parts. > Additionally, make sure that the branch bootstraps and tests on all > primary/secondary platforms with all languages enabled. Diego, thanks for your prompt reply and suggestions. Regarding the primary/secondary platforms. Are those listed here? http://gcc.gnu.org/gcc-4.5/criteria.html We have access to only a few of the listed platforms, (and in the case of IA64 the underlying OS is SuSE not "unknown-linux-gnu"). How are the following targets handled? arm-eabi, mipsisa64-elf Are these cross-compilers targetting some sort of instruction set simulator? Is there "how to" for setting up those platforms and running tests? Given the nature of UPC we're not sure that some of those targets are applicable or will be initially supported; though I can certainly see the value of making sure that we don't break anything in the main line that would impact those platforms. Typically, how is this situation handled - where tests need to be run on hardware/software platforms that we don't have access to, prior to merging into the GCC trunk? thanks, - Gary
Re: why mult generated for unsigned int multiply on mips?
On Wed, 2010-04-07 15:05:09 +0800, Amker.Cheng wrote: > found the cause, sorry to disturb, please ignore this message. It would, however, be nice if you actually posted an answer to your (now solved) question. That way, any casual reader may learn something new. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second : signature.asc Description: Digital signature
[alpha] Wrong code produced at -Os, -O2, and -O3
Hi Uros and Richard, I was rewriting the Alpha sched_find_first_bit implementation for the Linux Kernel, and in the process I think I've come across a gcc bug. I rewrote the function using cmov instructions, and wrote a small program to test its correctness and performance. I wrote the function initially as an external .S file, and once I was reasonably sure it was correct, converted it to C function with inline assembly. Compiling both produce the exact same output, as shown. : ldq t0,0(a0) clr t2 ldq t1,8(a0) cmoveq t0,0x40,t2 cmoveq t0,t1,t0 cttzt0,t3 addqt3,t2,v0 ret In my test program, I found that when I executed the rewritten implementation _before_ the reference implementation that it produced bogus results. This only happens when using the C/inline asm function. When compiled with the external .S file, the results are correct. Attached is a tar.gz with my test code. Compile the test program with `gcc -O -mcpu=... find.c rewritten.S test.c -o test` with optional -D__REWRITTEN_INLINE and -D__REWRITTEN_FIRST. At -Os, -O2, or -O3 and -D__REWRITTEN_INLINE and -D__REWRITTEN_FIRST the program will produce incorrect results and assert(). At -O0 or -O1 or without one or both of the -D flags, it will produce correct results. I've tested with gcc-4.3.4 and gcc-4.4.2. Thanks. Let me know what I can do to help further. Matt Turner sched_find_first_bit.tar.gz Description: GNU Zip compressed data
Re: GCC primary/secondary platforms?
On 4/7/2010 9:17 AM, Gary Funck wrote: On 04/07/10 11:11:05, Diego Novillo wrote: Additionally, make sure that the branch bootstraps and tests on all primary/secondary platforms with all languages enabled. Diego, thanks for your prompt reply and suggestions. Regarding the primary/secondary platforms. Are those listed here? http://gcc.gnu.org/gcc-4.5/criteria.html Will there be a notification if and when C++ run-time will be ready to test on secondary platforms, or will platforms like cygwin be struck from the secondary list? I'm 26 hours into testsuite for 4.5 RC for cygwin gcc/gfortran, didn't know of any other supported languages worth testing. My ia64 box died a few months ago, but suse-linux surely was at least as popular as unknown-linux in recent years. -- Tim Prince
Re: GCC primary/secondary platforms?
On Wed, 2010-04-07 at 09:17 -0700, Gary Funck wrote: > On 04/07/10 11:11:05, Diego Novillo wrote: > > I would suggest splitting patches across reviewer domains. See > > previous merges from big branches for examples. This makes it easier > > for maintainers and reviewers to review the relevant parts. > > Additionally, make sure that the branch bootstraps and tests on all > > primary/secondary platforms with all languages enabled. > > Diego, thanks for your prompt reply and suggestions. Regarding > the primary/secondary platforms. Are those listed here? > http://gcc.gnu.org/gcc-4.5/criteria.html > We have access to only a few of the listed platforms, > (and in the case of IA64 the underlying OS is SuSE not > "unknown-linux-gnu"). > > How are the following targets handled? > arm-eabi, mipsisa64-elf Hi, I don't know if these are formally equivalent (any taker?) but on the compile farm we have arm-linux and mips64-linux machines. I don't think unknown/suse/whatever version of Linux makes any difference for the criteria. Feel free to apply for an account on the compile farm, instructions are given here: http://gcc.gnu.org/wiki/CompileFarm Sincerely, Laurent
Subversion Status
Has anyone else seen this error from trunk? $ svn status svn: Error at entry 15 in entries file for 'gcc/testsuite/g++.dg/warn': svn: Bogus date Even if I delete the gcc/testsuite/g++.dg/warn tree, an update brings the error back. svn is 1.6.9. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: lower subreg optimization
2010/4/6, Jim Wilson :
> On 04/06/2010 02:24 AM, roy rosen wrote:
> > (insn 33 32 34 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 0)
> > (plus:V2HI (subreg:V2HI (reg:V4HI 112) 0)
> > (subreg:V2HI (reg:V4HI 113) 0))) 118 {addv2hi3} (nil))
> >
>
> Only subregs are decomposed. So use vec_select instead of subreg. I see
> you already have a vec_concat to combine the two v2hi into one v4hi, so
> there is no need for the subreg in the dest. You should try eliminating
> that first and see if that helps. If that isn't enough, then replace the
> subregs in the source with vec_select operations.
>
> Jim
>
Thanks Jim,
I have implemented your suggestion and now I am using vec_select and
the subreg optimization does not decomopose the instruction.
The problem now is that I get stuck with redundent instructions (that
I translate to move insns).
For example:
(insn 37 32 38 7 a.c:25 (set (reg:V2HI 116)
(vec_concat:V2HI (vec_select:HI (reg:V4HI 112)
(parallel [
(const_int 0 [0x0])
]))
(vec_select:HI (reg:V4HI 112)
(parallel [
(const_int 1 [0x1])
] 121 {v4hi_extract_low_v2hi}
(expr_list:REG_DEAD (reg:V4HI 112)
(nil)))
This instruction eventually has to be optimized out somehow. It is
dealing with extracting V2HI from V4HI. V4HI is stored in a register
pair (like r0:r1) and V2HI would simply mean to take one of these
registers - this does not need an instruction.
I saw in arm/neon.md that they have a similar problem:
; FIXME: We wouldn't need the following insns if we could write subregs of
; vector registers. Make an attempt at removing unnecessary moves, though
; we're really at the mercy of the register allocator.
(define_insn "move_lo_quad_v4si"
[(set (match_operand:V4SI 0 "s_register_operand" "+w")
(vec_concat:V4SI
(match_operand:V2SI 1 "s_register_operand" "w")
(vec_select:V2SI (match_dup 0)
(parallel [(const_int 2) (const_int 3)]]
"TARGET_NEON"
{
int dest = REGNO (operands[0]);
int src = REGNO (operands[1]);
if (dest != src)
return "vmov\t%e0, %P1";
else
return "";
}
[(set_attr "neon_type" "neon_bp_simple")]
)
Their solution is also not complete.
What is the proper way to handle such a case and how do I let gcc know
that this is a simple move instruction so that gcc would be able to
optimize it out?
Thanks, Roy.
Re: [alpha] Wrong code produced at -Os, -O2, and -O3
On Wed, Apr 7, 2010 at 8:38 PM, Matt Turner wrote: > I was rewriting the Alpha sched_find_first_bit implementation for the > Linux Kernel, and in the process I think I've come across a gcc bug. [...] > Thanks. Let me know what I can do to help further. Please fill a Bugzilla bugreport with your problem. Otherwise, it will be lost in the mailing lists. Uros.
