Regarding concrete inlined and out-of-line inlined instances

Hi, I have the below debug information (dwarf4) generated by the GCC compiler v4.8.2 for an inlined function. Please help me with the following queries. In the concrete inlined instance of 'ext2_lookup', its DW_AT_entry_pc value (0xc01b49d0) is overlapping with the address range i.e. DW

[GCC 4.8.1] Which section to emit, .eh_frame or .debug_section?

Hi, For C++ applications, on PPC, gcc v4.8.1 is generating the call frame information in the .eh_frame section by default. Could you please tell me why .eh_frame is being generated instead of .debug_frame? Also, the dwarf4 standard does not describe .eh_frame section. I understand that by default

Re: [GCC 4.8.1] Which section to emit, .eh_frame or .debug_section?

On Thu, Feb 13, 2014 at 5:29 PM, Jakub Jelinek wrote: > On Thu, Feb 13, 2014 at 05:24:53PM +0530, Ramana wrote: >> For C++ applications, on PPC, gcc v4.8.1 is generating the call frame >> information in the .eh_frame section by default. >> >> Could you please tel

Re: CSE not combining equivalent expressions.

was removing (2) and retaining just (1) . Alas , don't have logs handy now. Also this is removed for the case of integers by the CSE pass IIRC . The problem arises only for the type being a char or a short. ~ramana Mircea -- Ramana Radhakrishnan

Re: CSE not combining equivalent expressions.

to me this could be done in the propagation engine. Basically we keep track of the known zero, sign bit copies and known nonzero bits for SSA names, then propagate them in the obvious ways. The obvious way is at IL lowering time. Basically replicating a lot of what combine & cse do in this area, but at the tree level. It's something I've always wanted to see implemented, but never bothered to do... jeff -- Ramana Radhakrishnan

[DataFlow Branch] Query regarding an ICE in global.c

infrastructure. I am still feeling my way through the df code , so any help would be appreciated. Thanks in advance. This is with revision 123253 of the DF branch which is slightly older . I am considering moving up but wanted to check before that . cheers Ramana -- Ramana

Re: [DataFlow Branch] Query regarding an ICE in global.c

On Wed, 2007-04-18 at 19:54 +0530, Ramana Radhakrishnan wrote: > Hi , > > I am working on integrating a private port into the Dataflow branch and > am running into a couple of issues with ICEs in global.c . The ICE is > at gcc_assert ( REGS_LIVE (i)) at line 534 in global_allo

Re: [DataFlow Branch] Query regarding an ICE in global.c

On Wed, 2007-04-18 at 10:35 -0400, Kenneth Zadeck wrote: > Ramana Radhakrishnan wrote: > > Hi , > > > > I am working on integrating a private port into the Dataflow branch and > > am running into a couple of issues with ICEs in global.c . The ICE is > > at gcc_as

Re: Obsoleting more ports for 4.0.

Hi, Resending for the archives, since the spam bot on sourceware did not like so many recipients with my address. Hope it works this time and apologies for duplicate messages . cheers Ramana Original Message Subject: Re: Obsoleting more ports for 4.0. Date: Tue, 22 Mar 2005 18

Re: Problem in assembly and linking(gcc-4.0)

with using gcc. cheers Ramana -- Ramana Radhakrishnan GNU Tools codito ergo sum (www.codito.com)

Re: Adding an instruction to gcc (pass through)

Errr, you need to change the assembler to do this . GCC does not care about what sits inside __asm__ . cheers Ramana On Fri, 2005-12-16 at 09:18 -0500, Burt Walsh wrote: > > > I am using SimpleScalar (ARM ISA) to do some simulations. I have > added an > instruction to t

Re: debug-early branch merged into mainline

7;m seeing bootstrap failures on arm-none-linux-gnueabihf gcc/cfgloop.o differs gcc/tree-ssa-dom.o differs gcc/dwarf2asm.o differs gcc/tree-affine.o differs gcc/cse.o differs gcc/data-streamer-out.o differs gcc/tree-ssa-sccvn.o differs regards Ramana > > and on ia64: > > ../../gcc/dw

Re: ARM's Changing Call Used Registers Causes Weird Bugs

t obeying the ABI and clobbering D8. If you have an actual reproducible issue please report it on bugzilla following the rules for reporting bugs by producing a standalone testcase. as documented here https://gcc.gnu.org/bugs/ Thanks, Ramana > -- > Lin Zuojian

Re: GCC 5.1.1 Status Report (2015-06-22)

eral back-ends. I'd also like to see the ARM patches backported please unless there are RM objections for it. It doesn't make sense for them to diverge with something like this at different release points on the branch if we can avoid it. Ramana > > Matthew

Re: [AArch64] Missed vectorization opportunity in cactusADM

>> yes, that '50' should be a parameter somewhere in loop_vec_info. > > I see the broken code is still in aarch64.c - can someone please test > & apply the above > patch? I believe this is on Alan's todo list. Ramana > > Thanks, > R

Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

; So this is a regression in fsf-5. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916#c3 regards Ramana > > Kind regards, > Alex >

Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

ons of the compiler, and the debate has been whether this is a regression or not. If in case it is not deemed to be a regression based on that comment, we should just XFAIL the test and move on. Given Jakub's away I'm CCing richi on this discussion. regards Ramana > > Kind regards, > Alex >

Re: Moving to git

f "next" I've seen is with gerrit, where "next" refers to a "next" commit that's been put up for code review. > > One interesting thing that they do is to keep earlier branches merged into > later branches, so 4.9 into 5, 5 into trunk, trunk into next. This is an > interesting discipline, but I'm not sure it is of much practical value. I don't see how that fits with our development model. regards Ramana > > Jason >

Re: Moving to git

On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely wrote: > On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: >>> >>> Absolutely, a non-fast-forward push is anathema for anything other people >>> might be working on. The git repository already prohibits this

Re: Moving to git

On Fri, Aug 21, 2015 at 3:09 PM, Andreas Schwab wrote: > Ramana Radhakrishnan writes: > >> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely >> wrote: >>> Teams following a different model could use a separate repo shared by >>> those developers, not the gcc

Re: Moving to git

On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote: > On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote: >> Ramana Radhakrishnan writes: >> >> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely >> > wrote: >> >> Teams following a differ

Re: Moving to git

On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote: > On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote: >> Ramana Radhakrishnan writes: >> >> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely >> > wrote: >> >> Teams following a differ

Re: dejagnu version update?

me ? Advantage is that everyone is guaranteed to be on the same version. I fully expect resistance due to specific issues with specific versions of tcl and expect, but if folks aren't aware of this . regards Ramana

Re: Repository for the conversion machinery

ust avoiding it. After all the information is in the changelog and in the commit - currently svn log shows username with an implicit gcc.gnu.org. I can certainly say I'm in those shoes - you can work that out from the Changelogs and I'm sure there may be others too. It sounds like gcc.gnu.org is the safest map for everyone. regards Ramana > > - FChE

Re: dejagnu version update?

On Wed, Sep 16, 2015 at 11:27 PM, Mike Stump wrote: > On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan > wrote: >> >> Sorry about the obvious (possibly dumb) question. > >> Can't we just import a copy of dejagnu each year and install it as part of >>

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

is dependent as usual on command line options, target options, pragmas etc ? regards Ramana

Re: How do we write unused arguments?

> one comments, I'll start enforcing that in patch reviews. Currently no one > seems sure and everything is getting totally inconsistent. When I asked on IRC the other day it sounded like people were tending towards some_target_hook (tree decl, machine_mode) and that's what I'm starting to use personally these days. regards Ramana > > > Bernd

Re: Instruction scheduler rewriting instructions?

about PR 48814 and ivopts (thus the -fno-ivopts option). IIRC it's because the scheduler *thinks* it can get a tighter schedule - probably because it thinks it can dual issue the lbu from $4 and the addiu to $5. Can it think so ? This may be related - https://gcc.gnu.org/ml/gcc-patches/2012-08/ms

Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

o check the transformation - I think you need to check for __ARM_ARCH_EXT_IDIV__ here similar to the way in which we test for FMA or __ARM_FEATURE_UNALIGNED. Could you please repost with the changes so that I can take another look ? Otherwise I think this is something we should queue up for GCC 7. thanks, Ramana

Re: How to check if two symbols are from same source unit during WPA ?

;implemented" using some special relocations and thus as linker > optimization. For performance (and probably code size too) as you can end up CSE'ing the anchor point. the difference in performance with -flto-partitions=1 is visible on quite a few of the spec2k benchmarks. I don't remember which ones immediately but yeah it makes a difference. Ramana > > Richard. >

Oliver Hainque as co-maintainer of the VxWorks port.

I am pleased to announce that the GCC Steering Committee has appointed Oliver Hainque as co-maintainer for the VxWorks port. Please join me in congratulating Oliver on his new role. Oliver, please update your listing in the MAINTAINERS file. Thanks, Ramana

Andrew Burgess and Claudiu Zissulescu as reviewers for the ARC port

, Ramana

Re: Live range shrinkage in pre-reload scheduling

> E.g. tracking pressure classes isn't always the right thing for > targets like PowerPC where only part of the vector register set > can be used for floating-point operations. Is there another post that deals with this particular case ? I tried digging through the archives but couldn't find anything easily enough. regards Ramana > > Thanks, > Richard

Re: Live range shrinkage in pre-reload scheduling

On Thu, May 15, 2014 at 8:36 AM, Maxim Kuvyrkov wrote: > On May 15, 2014, at 6:46 PM, Ramana Radhakrishnan > wrote: >> >>> >>> I'm not claiming it's a great heuristic or anything. There's bound to >>> be room for improvement. But it was

Re: Using particular register class (like floating point registers) as spill register class

84>: fmovd10, x0 >0x007fb76dc848 <+188>: add x0, x29, #0xf8 >0x007fb76dc84c <+192>: fmovd11, x0 > > followed later by: > >0x007fb76dd224 <+2712>: fmovx0, d9 >0x007fb76dd228 <+2716>: add x6, x29, #0x118 >0x007fb76dd22c <+2720>: str x20, [x0,w27,sxtw #3] >0x007fb76dd230 <+2724>: fmovx0, d10 >0x007fb76dd234 <+2728>: str w28, [x0,w27,sxtw #2] >0x007fb76dd238 <+2732>: fmovx0, d11 >0x007fb76dd23c <+2736>: str w19, [x0,w27,sxtw #2] > > which seems a bit suboptimal, given that these double registers now have > to be saved in the prologue. That looks a bit suspicious - Is there a pre-processed file you can put on to bugzilla for someone to take a look at with command line options et al ? I had a testcase that I was investigating a few days back from a benchmark that was doing SHA2 calculations. From my notes I'd been playing with REGISTER_MOVE_COST and MEMORY_MOVE_COST and additionally the extra moves appeared to disappear with -fno-schedule-insns. Remember however that on AArch64 we don't have sched-pressure on by default. regards Ramana >

Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

-fpu=vfpv3-d16 Did you add any other architecture specific options to your SPEC2k runs ? regards Ramana If you need exact numbers they can be found in the tables. If you have any comments and proposals, please feel free to write me. I try to take them into account next year.

Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

(as you know RedHat works on a server market) but unfortunately I have no such machine for SPEC benchmarking. Ramana

Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

I wonder how much of that is due to auto-vectorization (on LLVM, -O2+ turns it on, I suppose GCC is only on -O3?). From Ramana's point, there may be nothing serious if you haven't enabled NEON, though. Auto-vec is turned off when you have -mfpu=vfpv3-d16 . That implies No Neo

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

ines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. We then need to do the same on ARM especially for older architectures that don't have these sync patterns. Ramana Thanks,

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

x/arm-eabi-extra.ver to have added these symbols in and I'm not sure what's going on here. So prima-facie this is a bug. I wonder if something's broken in the handling of port_specific_symbol_files for arm. regards Ramana - HPPA (build log [2]), is missing all the fut

Re: [ARM] Is TARGET_UNIFIED_ASM still needed?

were to do the full transition, remember that users need to have a way of mixing non-unified syntax in inline assembler with unified syntax in the rest of the C code. regards Ramana Is it perhaps time to just drop this and assume unified asm everywhere? Kyrill

Re: [AArch64] Usage of FP regs whe only GP regs are allowed

e LRA from using FP registers if the user so desires. Please send patches to the mailing list. I think however in this case you are papering over the problem as explained in the PR. regards Ramana

Re: arm/thumb broken on head

; ../../gcc/gcc/passes.c:1868 > 0x870733 execute_todo > ../../gcc/gcc/passes.c:1925 > Please submit a full bug report, > with preprocessed source if appropriate. That certainly looks like a different issue to the one with Terry's patch. It does look like something else is br

Re: LRA handling of subreg (on AARCH64 with ILP32)

pear to store a 64 bit value on the stack and then reobtain into a different register set , ie. r6, r3 -> r6, r7 Ramana > > Thanks, > Andrew Pinski

Re: Failure to dlopen libgomp due to static TLS data

org/ml/libc-alpha/2014-10/msg00134.html though my brain is too frazzled today to remember what the conclusion was. regards Ramana > > One example of a system library that does this is libgomp, the OpenMP > support library provided with GCC. Here's an email thread from the > gcc

Re: [RFC] load/store widening question

ordering issues and you'll have quite a few variances between ports to make this work sensibly. regards Ramana > $ gcc t2.c -O3 -S > > $ cat t2.s > > ... > > main: > .LFB0: > .cfi_startproc > movla(%rip), %eax > movl%

Re: [RFC] cortex-a{53,57}-simd.md missing?

are merited it will be picked up. That being said I believe the current description isn't too bad on the Cortex-A53 - it's definitely better than having none at all. regards Ramana -- Best regards, Ilya Palachev

Re: interest for ARM/thumb multiversionning ?

On 29/04/2015 09:24, Christian Bruel wrote: Hi Ramana, Richard After playing with the attritute ((target ("[thumb,arm]")), during the pending review, I added the "default" selector to neutralize -mflip-thumb for the setjmp/longjmp based tests. I was wondering it there

Re: Compilers and RCU readers: Once more unto the breach!

ng, though. The scheduler for e.g. is free to reorder if it can prove there is no dependence (or indeed side-effects for y) between insns produced for y and `x = z'. regards Ramana David

Re: Compilers and RCU readers: Once more unto the breach!

On 20/05/15 15:03, Paul E. McKenney wrote: On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote: On 20/05/15 14:37, David Howells wrote: Paul E. McKenney wrote: I was thinking of "y" as a simple variable, but if it is something more complex, then the compile

Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)

you probably need 2 smlald instructions to achieve this IIUC . We do have a dot product optab in the arm backend but that's with Advanced simd which isn't in the M profile. regards Ramana > > Would the test be suitable if it made the arm target, > with a patch added to add a s

Re: autovectorization in gcc

ical. It would be nice > to have a warning which would fire if vectorization failed. That would > surely help the OP. That would help certainly : the user could get some information out today with the debug dumps - however they are designed more for the compiler writers rather than users. regards Ramana

Re: GCC missing -flto optimizations? SPEC lbm benchmark

Just it is better not to have it if > it causes lots of wrong-code issues and there is nobody to fix those. I also remember a cauldron talk in the recent past about this. It was in Prague. Ah , here's a youtube video of it. : https://www.youtube.com/watch?v=vhV75sys0Nw Ramana > > Jakub

Re: Doubts regarding the _Dependent_ptr keyword

On Tue, Jul 2, 2019 at 1:29 AM Akshat Garg wrote: > > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote: >> >> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan >> wrote: >>> >> [CCing gcc mailing list] >> >> So, shall I start looki

Re: Doubts regarding the _Dependent_ptr keyword

itive nature of >> assignments with these attributes ? >> >> regards >> Ramana > > I don't understand what information to store, can you explain? I was thinking > of putting some code inside the pass, which breaks the dependency chains, > which w

Re: Doubts regarding the _Dependent_ptr keyword

nder if marking this volatile would be sufficient for prototyping. I suspect we would need another flag somewhere which someone with gimple knowledge might be able to help us with. regards Ramana > > Thanx, Paul > > > Ramana > >

Kyrylo Tkachov and Richard Sandiford appointed AArch64 maintainers.

file. Thanks, Ramana

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

re for use only on bare-metal targets. > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > aarch64-linux-elf... > > I get a KeyError in build_compilers and build_glibcs when it tries to look > > up the config with either of those values. > > > > Unfortunately the build-many-glibcs.py does not have support for baremetal > build yet (since it is a tool created to build cross-compiling toolchain > using glibc). And glibc doesn't work bare-metal .. regards Ramana

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

on bare-metal > > targets. > > > > > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > > > aarch64-linux- > > elf... > > > > I get a KeyError in build_compilers and build_glibcs when it tries to > > > > look up

Re: Linux and Windows generate different binaries

On Wed, Jul 12, 2017 at 3:57 PM, Sandra Loosemore wrote: > On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote: >> >> I have seen reproducible builds being discussed here, but what is the >> position on inter c-lib and OS reproducible builds? > > > I think we consider unstable sort problems

Announcing ARM and AArch64 port maintainers.

it would be appreciated. Thanks, Ramana

Re: Help out/New to the Project

wiki page here https://gcc.gnu.org/wiki/EasyHacks regards Ramana > > Thanks for any answers, > Nick

Re: "GOT" under aarch64

er the question when are relocations through the GOT used, the answer is whenever folks want to have position independence either in their libraries or in their executables. regards Ramana

Re: Fw: GCC interpretation of C11 atomics (DR 459)

is a guarantee from the standard that there are no problems with read-only locations is to implement the change in libatomic. You cannot have the same region of memory protected by locks in older binaries and the appropriate load / store instructions in new binaries. Ramana > 4. Faster & e

Richard Sandiford appointed SVE maintainer in AArch64 port.

I am pleased to announced that the GCC Steering Committee has appointed Richard Sandiford as SVE maintainer in the AArch64 port. Please join me in congratulating Richard on his additional role. Richard, please update your listing in the MAINTAINERS file. regards Ramana

Re: Dealing with default recursive procedures in Fortran

IIRC that will have a dependency on a newer glibc as well,so that would depend on a newer glibc as well for split-stack to work reliably as platforms. Ramana

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

they pop up over time. The expression "all cases we can identify" is > the core of the problem; it's not a well-defined set. > > Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a > pin-point location; another possibility (that might scale better to > humans) is a new, lighter-weight flag, such as "-mno-multiple", that is > applied universally to a codebase. I don't see enough detail to explain what the problem is in the first place. LTO to me is a red-herring here and smells of a hack. There's no guarantee that GCC won't use these instructions in non-LTO configurations and infact will aggressively do this in a number of situations. The -fno-lto fix and the fix for disabling load / store multiple or load / store pair being suggested here both smell of an underlying problem that needs to be understood in the various sourcebases first. Ramana > > Thanks! > Laszlo

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

till holds, it's not a question of an architecture bug or a >> >> > missing feature in KVM, but a question of a guest doing something wrong. >> >> > >> >> >> >> Do you have a mutt macro for that response? :-) >> >> >> > >> > No I don't. And I wouldn't mind adding instruction decoding to KVM. I >> > already wrote it once, but the maintainer didn't want to merge the code >> > unless I unified all instruction decoding in the arm kernel, which I was >> > unable to do. >> > >> >> Yikes. >> >> So how does your code actually load the opcode? >> >> > Sarkasm and instruction decoding stories aside, we've had a number of >> > reports of this kind of error in the past where the problem was simply >> > people using the wrong the DT with their guest kernel. I don't think >> > we've seen an actual case of a real guest that was using the 'wrong' >> > instruction to actually do I/O. >> > >> >> Currently, LTO builds of EDK2 for 32-bit mach-virt are broken because >> of this. The MMIO accessors are written in C using volatile pointers, >> allowing LTO to merge adjacent accesses or loops performing MMIO, >> resulting in, e.g., instructions with writeback to be emitted. > > I'd like to see a testcase where GCC does merging on volatile accesses. > That would be a GCC bug. So I suspect the C code isn't quite using volatile > accesses... > I'd also like to see a proper testcase to action. IIRC we have checks preventing such merges for volatiles irrespective of LTO or not. Ramana

Re: Subnormal float support in armv7(with -msoft-float) for intrinsics

tches to. regards Ramana > ~Umesh > > On Fri, Jul 13, 2018 at 1:22 PM, Umesh Kalappa > wrote: >> Thank you and issue raised at >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512 >> >> ~Umesh >> >> On Thu, Jul 12, 2018 at 9:33 PM, Szabolcs Nagy wrote:

Re: GCC 8.2 Status Report (2018-07-19), branch frozen for release

; https://gcc.gnu.org/ml/gcc/2018-07/msg00194.html Is there any chance we can get some of the spectrev1 mitigation patches reviewed and into 8.2 . It would be quite useful to get these into a release as I see that the reviews are kinda petering out and there hasn't been any objection to the approach. regards Ramana

Re: [RFC] Adding Python as a possible language and it's usage

gt; dependencies, use in glibc is more or less equivalent to use in GCC. (But > if build dependencies include those involved in testing, you already have > python as one for glibc, and Tcl for GCC, for example.) This implies that the decision for glibc has been made. while you imply above that the discussion is still on going ? regards Ramana > > > Joseph S. Myers > jos...@codesourcery.com

Re: Second GCC 4.6.0 release candidate is now available

nd it just seemed to work. I'm still looking through the other results but I haven't spotted anything obvious broken yet. cheers Ramana On Thu, Mar 24, 2011 at 9:04 PM, Michael Hope wrote: > On Tue, Mar 22, 2011 at 11:12 AM, Jakub Jelinek wrote: >> A second GCC 4.6

Re: regrename and odd behaviour with early clobber operands

On 16 August 2011 16:24, Richard Sandiford wrote: > Ramana Radhakrishnan writes: >> I can't see how it is right to construct essentially 2 chains for the >> same register that have overlapping live ranges without an intervening >> conditional branch and since regrename

Re: A question abt finding all register uses in instruction

he destination register involved in this case in that the lower order bits of the register are left unchanged ? cheers Ramana

RE: [RFC, ARM] cortex_a8_call cost

k splitting is a consequence of that. For the A8 this should be OK - try a few benchmarks to be sure it doesn't spring any surprises performance wise. cheers Ramana --- Ramana Radhakrishnan PDSW Tools ARM Ltd.

Re: __sync_sychronize on ARM

static libgcc where this should be defined. I don't know what your linker command line is so maybe that's a place to start investigating from. cheers Ramana

Re: PRE_DEC, POST_INC

ing to address auto-inc generation for loop ivopts but I'm not sure if these have gone into trunk yet. Hope this helps. cheers Ramana

ifcvt.c question.

ith this email. Thanks in advance for the answers. cheers Ramana Attachments 1. Patch to turn on predicable attributes on all the ARM call patterns. 2. Dumps of the testcase that are relevant, test.c.*.peephole2, test.c.*.dse2, test.c.*.ce3. (dumps.tar.bz2) 3. Testcase test.c -- Ram

Re: ifcvt.c question.

On Mon, 2009-08-10 at 15:09 +0200, Steven Bosscher wrote: > On Mon, Aug 10, 2009 at 1:16 PM, Ramana > Radhakrishnan wrote: > > I wonder if the best way to fix this is to teach ifcvt.c to handle > > conditional returns. > > Yes. This is a bug in the middle-end. I can only

Re: irc.oftc.net down?

On Wed, Aug 19, 2009 at 1:27 PM, Diego Novillo wrote: > I haven't been able to connect to #gcc today.  Is anyone else having > trouble connecting? Wonder if it is something else . I've been connected pretty much all day and things seem to be working. Ramana > > Diego. >

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

instructions after the patch be less than the number of zero-extension instructions before or is this a regression ? Thanks, Ramana > > > I have attached the latest patch : > > > On Sun, Aug 9, 2009 at 2:15 PM, Richard Guenther > wrote: >> On Sat, Aug 8, 2009 at 11:59

Re: Unnecessary PRE optimization

wprop patch I'm happy to test for performance on the ARM and look at ADDRESS_COST carefully on the ARM. cheers Ramana > > Paolo

[ARM] Neon / Ocaml question

ters 0-10: Unbound module Utils It sounds like a configuration issue but given my rather rusty ocaml skills - I'm not sure where to look. Googling around doesn't show me anything obvious. I see this both with v. 3.09.3 and v 3.11 (on karmic). Any help would be appreciated.

Re: [ARM] Neon / Ocaml question

s you beat me to it. cheers Ramana -- Ramana Radhakrishnan GNU Tools ARM Ltd.

Re: GCC 4.4.3 Release Candidate available from gcc.gnu.org

, so that some spurious Neon test failures go away. Can I also ask to backport the fix for http://gcc.gnu.org/PR40887 into the 4.3 / 4.4 branches ? Cheers Ramana

Re: GCC 4.5 Status Report (2010-03-15)

> 42509, arm-gnueabi doesn't bootstrap but is a primary target I haven't had the time in the past few weeks to work on this effectively. I'll be able to find some time to work on this during this week and will get back on this. cheers Ramana

inconsistencies in the documentation regarding side effects with auto inc-dec

ss shortly before or after; these cases are then transformed to use pre- or post-increment or -decrement. Cheers Ramana

query regarding adding a pass to undo final value replacement.

to resolve them well enough yet. Whilst doing so, I wanted to check on the approach as outlined below and ask if there's anything that we might have missed or any problem that one can see with us going along these lines. Thanks for your time and patience. cheers Ramana 1) Understanding w

Re: query regarding adding a pass to undo final value replacement.

ased on the hashes calculated we don't undo the change. > -- in case more complex loop transformations were performed > (e.g., loop reversal), the final value of the ssa name might have > changed. Could you give an example for this ? Is there anything else you might sugges

eamonn raymona deepak

camille laura maryam

Re: query regarding adding a pass to undo final value replacement.

thing else you might >> suggest in terms of undoing the transformations from scalar cprop.? > > I would probably try to somehow pass the information from scev analysis > to value numbering, and let PRE take care of the issue, I do not know the value numbering code or the scev code well enough to attempt this immediately. I'm trying to see if this intermediate solution is good enough for the time being. > > Zdenek > -- Ramana Radhakrishnan

Re: query regarding adding a pass to undo final value replacement.

ng the computations inside the loop, just about the phi node, Well since the phi node with a single operand depends on statements / operations within the loop, the hashcode computed initially and finally need to match. If the computations within the loop change then clearly the hash values at the time of storing and restoring would be different . So if the assignment to D.10_1 has changed in some form, the hashvalues would be different. > > Zdenek > -- Ramana Radhakrishnan

Re: query regarding adding a pass to undo final value replacement.

(use_p, stmt, iter, SSA_OP_USE) { tree use = USE_FROM_PTR (use_p); val += get_stmt_hash (use); val += gen_hash (SSA_NAME_DEF_STMT (use)); } } else val += generate_phi_node_hashcode (stmt); return val; } and one calls this in continuation to my earlier email by arg_p = PHI_ARG_DEF_PTR (phi_node , 0); op0 = USE_FROM_PTR (arg_p); val = iterative_hash_expr (op0, val); if (TREE_CODE (op0) == SSA_NAME) { val = iterative_hash_expr (SSA_NAME_VAR (op0), val); val += SSA_NAME_VERSION (op0); val += gen_hash (SSA_NAME_DEF_STMT (op0)); } cheers Ramana > > Zdenek > -- Ramana Radhakrishnan

Re: query regarding adding a pass to undo final value replacement.

the same hash value. > 4) SSA_NAME_DEF_STMT (op0) may have been removed, so this would > be accessing garbage. I've already hit 2 whilst building with the patch and I agree that hashing through the uses is going to make compilation very slow. I don't see an easy option then to add the checks for hashing the SSA names . Is there something else that I could try ? cheers Ramana > > Zdenek > -- Ramana Radhakrishnan

Re: STRIP NOPS Question

You need to define your pipeline automaton and then insert nops to avoid data hazards using machine_reorg or a trick as described by Ian here. http://gcc.gnu.org/ml/gcc/2006-03/msg00627.html cheers Ramana > > Any help is greatly appreciated! > > Please CC me in your

query regarding iterating DOM on jump threading oppurtunities

ing DOM if jump threading is turned on in the 4.3 branch. I know there are a number of changes I need to do and I'm looking into them. I wanted to check back if you still had any record of the small number of performance regressions that you mention in the posting of the afore mentioned patch. Thanks, Ramana

PR 39076 Backport a patch for GCC 4.3

it ok to backport this patch into gcc-4.3 after regression testing? cheers Ramana

Re: ARM compiler rewriting code to be longer and slower

d` -S -Os newpr.c -fno-tree-ccp -fno-tree-fre -fno-tree-vrp -fno-tree-dominator-opts -fno-gcse I'm not sure about the best way to fix this but I've filed this for the moment as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468 cheers Ramana --- Ramana Radhakrishnan ARM Ltd.

RE: ARM compiler rewriting code to be longer and slower

nly solve the problem within an extended basic block and not necessarily across the program ? Surely you'd want to do it globally or am I missing something very basic here ? Ramana

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

> To aid testing, I'd like people to help bootstrapping bootstrappable > targets -- arm, alpha, ia64, pa, s390, x86_64. I'm bootstrapping the branch on an arm-linux-gnueabi target. Ramana

  1   2   >