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
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
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
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
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
:38:49 +0530
From: Ramana Radhakrishnan <[EMAIL PROTECTED]>
To: Kazu Hirata <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Saurabh Verma <[
with using
gcc.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
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 the SimpleScalar machin
On Sat, Jun 6, 2015 at 10:49 AM, Andreas Schwab wrote:
> Bootstrap fails on aarch64:
>
> Comparing stages 2 and 3
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap compar
On Mon, Jun 8, 2015 at 9:07 AM, lin zuojian wrote:
> Hi,
> in arm.c
> static void
> arm_conditional_register_usage (void)
> ...
> if (TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP)
> {
> /* VFPv3 registers are disabled when earlier VFP
> versions are selected
On Thu, Jul 2, 2015 at 12:03 PM, Matthew Wahab
wrote:
> On 22/06/15 12:56, Richard Biener wrote:
>>
>>
>> I plan to release GCC 5.2.0 around July 10th which means a release
>> candidate being done around July 3rd.
>>
>> Please check your open regression bugs for ones that eligible for
>> backporti
>> 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,
> Richard.
>
>> Richard.
>>
>>> Thanks,
>>> James
>>>
>>> ---
>>> [
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300)
> spawn
> Hi Marcus,
>
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeou
>
> Absolutely, a non-fast-forward push is anathema for anything other people
> might be working on. The git repository already prohibits this; people that
> want to push-rebase-push their own branches need to delete the branch before
> pushing again.
On the FSF trunk and the main release branche
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
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
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
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
On 16/09/15 17:14, Mike Stump wrote:
> On Sep 16, 2015, at 12:29 AM, Andreas Schwab wrote:
>> Mike Stump writes:
>>
>>> The software presently works with 1.4.4 and there aren’t any changes
>>> that require anything newer.
>>
>> SLES 12 has 1.4.4.
>
> Would be nice to cover them as well, but th
On Wed, Sep 16, 2015 at 6:06 PM, Frank Ch. Eigler wrote:
> Hi -
>
>> [...]
>> >- rewrite history - use some totally arbitrary, and quickly outdated,
>> >internet identity
>
>> I think this is main reason why @gnu.org or @gmail.com style addresses
>> are preferred over employer addresses when there
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
>>
On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote:
> On Wed, 7 Oct 2015, Jeff Law wrote:
>
>> I'm not sure why this attribute isn't documented, but clearly that should be
>> fixed.
>
> I assume the reasoning was: we document support for Cilk+ (and what's
> included in Cilk+ is externally document
On Thu, Nov 5, 2015 at 9:32 AM, Bernd Schmidt wrote:
> When reviewing patches I'm never quite sure which of the following we should
> be using:
>
> some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED)
>
> some_target_hook (tree decl, machine_mode ARG_UNUSED (mode))
>
> some_target_hook
On Thu, Dec 3, 2015 at 7:01 PM, Steve Ellcey wrote:
> Can the instruction scheduler actually rewrite instructions? I didn't
> think so but when I compile some code on MIPS with:
>
> -O2 -fno-ivopts -fno-peephole2 -fno-schedule-insns2
>
> I get:
>
> $L4:
> lbu $3,0($4)
>
Hi Prathamesh,
Could you split out the ARM specific portions into a separate patch
please in a patch series?
>@deftypefn {Target Hook} void TARGET_EXPAND_DIVMOD_LIBFUNC (bool
>@var{unsignedp}, machine_mode @var{mode}, @var{rtx}, @var{rtx}, rtx
>*@var{quot}, rtx *@var{rem})
>Expand divmod libfun
>
> What happens in practice? GCC doesn't put functions in random
> partitions.
>
The data goes into a separate partition AFAIU - it means that all data accesses
are as though they are extern references which means there's not necessarily
any CSE'ing ability that's available with section anc
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
I am pleased to announce that the GCC Steering Committee has
appointed Andrew Burgess and Claudiu Zissulescu as reviewers for
the ARC port.
Please join me in congratulating Andrew and Claudiu on their new roles.
Claudiu / Andrew - please update your listing in the MAINTAINERS file.
Thanks,
Raman
On Wed, May 14, 2014 at 5:38 PM, Richard Sandiford
wrote:
> Vladimir Makarov writes:
>> On 2014-05-13, 6:27 AM, Kyrill Tkachov wrote:
>>> Hi all,
>>>
>>> In haifa-sched.c (in rank_for_schedule) I notice that live range
>>> shrinkage is not performed when SCHED_PRESSURE_MODEL is used and the
>>> c
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
On Mon, May 19, 2014 at 1:02 PM, Andrew Haley wrote:
> On 05/16/2014 05:20 PM, Ian Bolton wrote:
>>> On 05/16/2014 12:05 PM, Kugan wrote:
On 16/05/14 20:40, pins...@gmail.com wrote:
>
>
>> On May 16, 2014, at 3:23 AM, Kugan
>>> wrote:
>>
>> I would like to know
On 24/06/14 15:11, Vladimir Makarov wrote:
A few people asked me about new performance comparison of latest GCC
and LLVM. So I've finished it and put it on my site
http://vmakarov.fedorapeople.org/spec/
The comparison is achievable from 2014 link and links under it in
the left frame.
The ball-park number you have probably won't change much.
Unfortunately, that is the configuration I can use on my system because
of lack of libraries for other configurations.
Using --with-fpu={neon / neon-vfpv4} shouldn't cause you ABI issues with
libraries for any other configurations.
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 Neon.
Ramana
Also
On 01/07/14 20:58, John David Anglin wrote:
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
On 1 July 2014 09:40, Matthias Klose wrote:
- HPPA (build log [2]), is missing all the future_base symbols and
exception_ptr13exception symbols, current_exception and
rethrow_exception.
This i
On 01/07/14 09:40, Matthias Klose wrote:
on some linux architectures there are some symbols missing in libstdc++.so.6
built from the 4.9 branch. I didn't notice before due to a packaging bug.
affected are ARM32, HPPA, SPARC.
- ARM32 (build log [1], both soft and hard float) are missing
On 22/07/14 14:14, Kyrill Tkachov wrote:
Hi all,
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
for Thumb-2. */
I've been doing some work
On 04/08/14 23:34, Evandro Menezes wrote:
I noticed that when -mgeneral-regs-only FP registers are still used by the
LRA for spilling. Though in rare cases I saw an ICE because of it, even
when it works it seems to me that the compiler should follow the desires of
its user.
If you've notice
On Tue, Nov 11, 2014 at 3:16 PM, Joel Sherrill
wrote:
>
>> Fix is committed to trunk at
>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217341.
>>
>> BR,
>> Terry
>>
> That got past libgcc2 but now it fails building newlib for arm-eabi.
> This is just a build of gcc with newlib and libgl
On Thu, Jan 15, 2015 at 4:11 AM, Andrew Pinski wrote:
> Hi,
> I have some code where we generate some weird code that has stores
> followed by a load from the same location.
> For an example we get:
> add x14, sp, 240
> add x15, sp, 232
> str x14, [sp, 136]
> mov w2, w27
> ldr w1, [sp, 136]
> st
On Thu, Feb 12, 2015 at 3:18 PM, Ulrich Weigand wrote:
> Hello,
>
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extension that a
On Thu, Feb 19, 2015 at 9:17 AM, Marat Zakirov wrote:
> Hi all!
>
> During my investigation I found that GCC does not performs load/store
> widening (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088). Could you
> please answer is it so? And is there any plans to make it? I also would like
> to k
;; Crude Advanced SIMD approximation.
(define_insn_reservation "cortex_53_advsimd" 4
(and (eq_attr "tune" "cortexa53")
(eq_attr:q "is_neon_type" "yes"))
"cortex_a53_simd0")
Does it mean that all AdvSIMD ins
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 would be an interest lev
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 compiler could do this, right?
char *x;
y;
x = z;
Yeah. I presume it has to maintain the ordering, though.
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
On Thu, Nov 1, 2018 at 10:42 AM Joern Wolfgang Rennecke
wrote:
>
>
> On 30/10/18 08:36, Richard Biener wrote:
> > On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
> > wrote:
> >> I want to submit some vectorizer patches, what would be a suitable
> >> regression test?
> > I am sure you have
On Wed, Jan 9, 2019 at 9:50 AM Andrew Haley wrote:
>
> On 1/9/19 9:45 AM, Kyrill Tkachov wrote:
> > Hi Kay,
> >
> > On 09/01/19 08:29, Kay F. Jahnke wrote:
> >> Hi there!
> >>
> >> I am developing software which tries to deliberately exploit the
> >> compiler's autovectorization facilities by feed
On Fri, Feb 15, 2019 at 1:16 PM Jakub Jelinek wrote:
>
> On Fri, Feb 15, 2019 at 02:12:27PM +0100, Richard Biener wrote:
> > On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel
> > wrote:
> > >I never could understand, why field reordering was removed from GCC?
> >
> > The implementation simply
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
>>
>> It's worth figuring out what passes are doing this - however the worry
>> I have is that every pass now needs to be handling this case with
>> respect to pointer attributes. Is there some place that you are
>> storing said information and what is the transitive nature of
>> assignments with t
On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney wrote:
>
> Once a user-created non-dependent pointer is assigned to, it is OK to
> break the dependency.
Ok, that's good.
>
> Or am I missing the point here?
I was just trying to make sure we were on the same page. I wonder if
marking this volatil
Hi,
I'm pleased to announce that the GCC steering committee has appointed
Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers.
Please join me in congratulating them both on their additional roles
in the community. Kyrill / Richard, please update your listings in the
MAINTAINERS file.
Tha
On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella
wrote:
>
>
>
> On 25/11/2019 17:28, Andrew Dean via gcc wrote:
> >>> This completes successfully. However, when I then try to run the gcc
> >>> tests like
> >> so:
> >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> >>> aarc
On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean wrote:
>
> > > >>> I get errors like this:
> > > >>>
> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > > >>> 'rdimon.specs': No such file or directory
> > > >>>
> > > >>> I can see that the rdimon.specs flag is added based on
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
I'm pleased to announce that the steering committee has appointed
- James Greenhalgh as a full maintainer for the AArch64 port
and
- Kyrylo Tkachov as a full maintainer for the ARM port.
James & Kyrylo, if you could update your entries in the MAINTAINERS
file to reflect these roles, it would
On Sat, Sep 9, 2017 at 4:27 AM, nick wrote:
> Greetings All,
>
> I am interested in helping out with the gcc project. I understand there is a
> bugzilla I can get started on
> but is there anything else in terms of things I should be reading outside the
> core docs in the git tree
> and the docs
On Fri, Sep 22, 2017 at 12:29 PM, Wilco Dijkstra wrote:
> Hi,
>
> You'll get GOT relocations to globals when you use -fpic:
>
> int x;
> int f(void) { return x; }
>>gcc -O2 -S -o- -fpic
>
> f:
> adrpx0, :got:x
> ldr x0, [x0, #:got_lo12:x]
> ldr w0, [x0]
>
On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc
wrote:
> Thanks, everyone, for the output, it is very useful. I am just proposing to
> consider the change unless there are clear roadblocks. (Either design choice
> is probably OK with respect to the standard formally speaking, but there
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
On Thu, Apr 12, 2018 at 10:50 PM, Thomas König wrote:
> Hello world,
>
> with Fortran 2018, recursive is becoming the default. This will likely
> have a serious impact on many user codes, which often declare large
> arrays which could then overflow stacks, leading to segfaults without
> further ex
On Tue, Jun 5, 2018 at 9:16 AM, Laszlo Ersek wrote:
> On 06/05/18 08:04, Ard Biesheuvel wrote:
>> On 4 June 2018 at 20:10, Laszlo Ersek wrote:
>>> Hi!
>>>
>>> Apologies if this isn't the right place for asking. For the problem
>>> statement, I'll simply steal Ard's writeup [1]:
>>>
KVM on AR
On Thu, Jun 7, 2018 at 10:35 AM, Richard Biener
wrote:
> On Thu, Jun 7, 2018 at 10:45 AM Ard Biesheuvel
> wrote:
>>
>> On 7 June 2018 at 10:21, Christoffer Dall wrote:
>> > On Thu, Jun 07, 2018 at 09:56:18AM +0200, Ard Biesheuvel wrote:
>> >> On 7 June 2018 at 09:48, Christoffer Dall
>> >> wro
On Tue, Jul 17, 2018 at 10:41 AM, Umesh Kalappa
wrote:
> Hi Nagy,
>
> Please help us with your comments on the attached patch for the issue
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512)
>
> Thank you and waiting for your inputs on the same.
Patches should be sent to gcc-patc...@gcc.gnu
On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 8 branch is frozen for preparation of the GCC 8.2 release.
> All changes to the branch now require release manager approval.
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2018-07/msg001
On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers wrote:
> On Fri, 27 Jul 2018, Michael Matz wrote:
>
>> Using any python scripts as part of generally building GCC (i.e. where the
>> generated files aren't prepackaged) will introduce a python dependency for
>> distro packages. And for those distros t
Hi Michael,
Thanks for running these. I spent some time this morning looking
through the results, they largely look ok though I don't have much
perspective on the
the objc/ obj-c++ failures.
These failures here
For v7-a , A9 and Neon - these failures below:
> Running target unix
> FAIL: gfortra
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
> I appreciate any advise of how to resolve this -- should I add
>
> (*fun) (&XEXP (dest, 0), data); ?
Actually I don't see why not - a zero_extract on the LHS of an
expression is supposed to be a bit field insert on that register.
Isn't there an implicit read of the destination register involved
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.
On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote:
> The __sync_synchronize "legacy" sync function is intended to be used to
> perform an expensive data memory barrier operation. It is defined within
> libgcc in such a way that I *believe* means that, on most architectures,
> it is replaced with
On Fri, Aug 7, 2009 at 1:33 PM, Florent Defay wrote:
> Hi,
>
> I am working on a new port.
>
> The target machine supports post-increment and pre-decrement
> addressing modes. These modes are twice faster than indexed mode.
> It is important for us that GCC consider them well.
GCC does support ge
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
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
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.
>
>
> GCC bootstrap :
>
> Total number of zero-extension instructions before : 1456
> Total number of zero-extension instructions after : 5814
> No impact on boot-strap time.
You sure you have these numbers the right way around ? Shouldn't the
number of zero-extension instructions after the pa
On Wed, 2009-12-23 at 16:00 +0100, Paolo Bonzini wrote:
> On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
> > Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
> > this should be fixed? Or it requires extra patch?
>
> No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
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.
s you beat me to it.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
ARM Ltd.
On Sat, 2010-01-16 at 16:23 +0100, Jakub Jelinek wrote:
>
> The branch is now frozen and all checkins until after the final release
> of GCC 4.4.3 require explicit RM approval.
I would like to backport this patch http://gcc.gnu.org/PR38697
from mainline into the 4.3 and 4.4 branches, so that som
> 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
Hi Kenneth,
The documentation of auto-inc-dec still refers to flow and when I
raised this on IRC folks suggested that you might have some
documentation fixes if any, in this area.
http://gcc.gnu.org/onlinedocs/gccint/Incdec.html#Incdec
The lines in the doco are as below :
These embedded side ef
_insert' and 'remove_stmts_insert_phi_nodes'.
4) Summary of key datastructures.
~~
a) changed_stmts_table - Hash table to record scalar evolution
changes.
b) phi_nodes_info - Link list, whose each node contains a PHI node
and a count indicating the number of statements that replaced this
phi node as a result of scalar evolution analysis.
--
Ramana Radhakrishnan
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
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
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
(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
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
response since I am not a subscribed to this list.
>
> Yours Sincerely,
>
> Balaji V. Iyer.
>
>
>
> --
>
> Balaji V. Iyer
> PhD Candidate,
> Center for Efficient, Scalable and Reliable Computing,
> Department of Electrical and Computer Engineering,
> North Carolina State University.
>
>
>
--
Ramana Radhakrishnan
Hi Jeffrey,
I'm seeing a few performance regressions similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315 in a port where I'm
working off the 4.3 branch. These regressions are caused by the
decision to stop iterating DOM on identifying
Hi Mark,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076 appears to be an
reappearance of the failure reported originally at
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html . and detailed
discussion in the thread that ends at
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00907.html .
Is
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.
[Resent because of account funnies. Apologies to those who get this twice]
Hi,
> > This problem is reported every once in a while, all targets with
> small
> > load-immediate instructions suffer from this, especially since GCC
> 4.0
> > (i.e. since tree-ssa). But it seems there is just not enoug
> 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
On Tue, Apr 7, 2009 at 11:03 AM, Ramana Radhakrishnan
wrote:
>> 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.
bootstrap on
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ramana Radhakrishnan
> Sent: 08 April 2009 23:30
> To: Paolo Bonzini
> Cc: GCC Development; Ian Lance Taylor; Andreas Krebbel; Uros Bizjak
> Subject: Re: [cond-opta
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Nitin Garg
> Sent: 01 May 2009 14:11
> To: gcc@gcc.gnu.org; gcc-h...@gcc.gnu.org
> Subject: Problem with gcc-4.4.0 with Cortex-m3 and cortex-a9 cpu
>
> I am working on Cortex-A9 and M3 of ARM
On Wed, May 6, 2009 at 4:10 PM, Mark Mitchell wrote:
> Richard Earnshaw wrote:
>
>>> The slush that I requested last week has been lifted. However, I have
>>> asked for relative calm until the cond-optab branch has been merged to
>>> mainline, which will hopefully occur on Friday, May 8th.
>>
>
1 - 100 of 149 matches
Mail list logo
