Hi, fellow GCC developers!
I was wondering if the "gcc" driver could be made to invoke
"cc1" twice, with different flags, and then just keep the
better of the two .s files that comes out?
I'm sure this is not a new idea, but I'm not aware of
anything being done in this area, so I've made this pos
Thanks for the quick response.
> On Thu, May 15, 2014 at 1:46 PM, Ian Bolton wrote:
> > Hi, fellow GCC developers!
> >
> > I was wondering if the "gcc" driver could be made to invoke
> > "cc1" twice, with different flags, and then just keep th
> 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 if there is anyway we can use registers from
> >>> particular register class just as spill registers (in place
> On Fri, May 16, 2014 at 6:34 AM, Sheheryar Zahoor Qazi
> wrote:
> >
> > I am trying to provide soft-fp support to a an 18-bit soft-core
> > processor architecture at my university. But the problem is that
> > libgcc has not been cross-compiled for my target architecture and
> some
> > functions
> >
> > Please can you try that on trunk and report back.
>
> OK, this is trunk, and I'm not longer seeing that happen.
>
> However, I am seeing:
>
>0x007fb76dc82c <+160>: adrpx25, 0x7fb7c8
>0x007fb76dc830 <+164>: add x25, x25, #0x480
>0x007fb76dc834 <+168>: f
Does anyone have some thoughts they'd like to share on this:
"When you compile anything using @file support, the driver assumes @file
(at_file_supplied is true) is allowed and may pass options to the linker via
@file using a *temporary* file.
When -save-temps is also used, the temporary @file pas
y grateful. Then, once we are on the same
page, I hope you could also make some suggestions as to how I might
help IRA work well with our instructions that can only use a subset
of the register bank.
Best regards, Ian Bolton (Compiler Engineer, Icera Inc.)
s the best output for a given
case? When it comes to optimisation, I prefer to bend the rules if at
all possible!
Best regards,
Ian
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: 16 October 2009 16:45
To: Vladimir Makarov
Cc: Ian Bolton; gcc@gcc.gnu.org
Subjec
both priority algorithm and the CB
algorithm, with ira-region=mixed and ira-region=one.
If you have any thoughts you'd like to share then I'd definitely be
interested, but this post is mainly because you said in a previous
email that you wanted to hear my suggestions :)
Best regards,
I
re an ETA on when reload will be gone away? ;-)
Best regards,
Ian
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: 22 October 2009 23:05
> To: Ian Bolton
> Cc: Vladimir Makarov; gcc@gcc.gnu.org
> Subject: Re: Understanding IRA
>
> On 10/
Dave Hudson wrote:
> On Thu, 2009-11-05 at 18:05 +0000, Ian Bolton wrote:
> > I think I may have made a breakthrough!
> >
> > As mentioned above, IRA is correctly increasing the cost for TOP_REGS
> > when an allocno in region 1 is being used in one of our special
> On 11/06/09 05:53, Dave Hudson wrote:
> > the most
> > critical thing was to ensure that REGNO_REG_CLASS was returning a
> > minimal class correctly.
> I believe that's been documented as the right thing to do for about 15
> years :-) So, yes, you definitely want REGNO_REG_CLASS to return the
Yesterday, I wrote:
> BTW, today I have achieved some good results with existing IRA by doing
> the following:
>
> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out before
> BOTTOM_REGS. My previous hacked version worked by increasing the
> priority of those that wanted BOTTOM_REGS,
Vladimir Makarov wrote:
> Ian Bolton wrote:
> > Yesterday, I wrote:
> >
> >> BTW, today I have achieved some good results with existing IRA by
> doing
> >> the following:
> >>
> >> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out
Ian Bolton wrote:
> Vladimir Makarov wrote:
> > Ian Bolton wrote:
> > > Yesterday, I wrote:
> > >
> > >> BTW, today I have achieved some good results with existing IRA by
> > doing
> > >> the following:
> > >>
> > &
Ian Bolton wrote:
> Ian Bolton wrote:
> > Vladimir Makarov wrote:
> > > Ian Bolton wrote:
> > > > Yesterday, I wrote:
> > > >
> > > >> BTW, today I have achieved some good results with existing IRA
> by
> > > doing
> > &
Jeff Law wrote:
> On 11/16/09 10:33, Ian Bolton wrote:
> > The question is: how to fix this? I have initially put the
> REG_ALLOC_ORDER
> > back to how it was and changed the operand constraints in our MD
> file,
> > so each of the "apathetic" instruction
From some simple experiments (see below), it appears as though GCC aims
to
create a lop-sided tree when there are constants involved (func1 below),
but a balanced tree when there aren't (func2 below).
Our assumption is that GCC likes having constants all near to each other
to
aid with tree-based o
David Edelsohn wrote:
> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton
> wrote:
> > From some simple experiments (see below), it appears as though GCC
> aims
> > to
> > create a lop-sided tree when there are constants involved (func1
> below),
> > but a balanced
Jeff Law wrote:
> Ian Bolton wrote:
> > Initial results showed that IRA was moving input arguments out of
> their
> > BOTTOM_REGS (e.g. $c1) into TOP_CREGS to do work on them, since it
> > thought TOP_CREGS were less costly to use, despite the cost of the
> move
>
Jeff Law wrote:
> >
> > I had an epiphany this morning and came up with an idea to achieve
> the
> > lookahead I thought I needed, thereby making the costs created by '?'
> a
> > lot more concrete and reliable.
> >
> > Firstly, I have altered the alt_cost adjustment (for '?') in ira-
> costs.c,
> >
For those who have been following my adventure in the world of IRA, or
just
want to take advantage of some of the time I've spent on this, here's a
detailed recap of my exploits and my current status (which I'm very
happy
with):
I initially thought IRA was calculating costs wrongly for our
archite
Let's assume I have two sub-classes of ALL_REGS: BOTTOM_REGS (c0-c15)
and TOP_CREGS (c16-c31).
Let's also assume I have two main types of instruction: A-type
Instructions, which can use ALL 32 registers, and B-type Instructions,
which can only use the 16 BOTTOM_REGS.
IRA will correctly calculate
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of
> Ian Bolton
> Sent: 18 December 2009 15:34
> To: gcc@gcc.gnu.org
> Subject: Possible IRA improvements for irregular register
architectures
>
> Let's assume I have two
-Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of
> Ian Bolton
> Sent: 04 January 2010 14:19
> To: gcc@gcc.gnu.org
> Subject: RE: Possible IRA improvements for irregular register
> architectures
>
> Happy New Year!
>
>
Near the end of assign_hard_reg in ira-color.c, there is this code:
if (min_full_cost > mem_cost)
{
if (! retry_p && internal_flag_ira_verbose > 3 && ira_dump_file !=
NULL)
fprintf (ira_dump_file, "(memory is more profitable %d vs %d) ",
mem_cost, min_full_cost);
,
Ian
> -Original Message-
> From: Vladimir Makarov [mailto:vmaka...@redhat.com]
> Sent: 21 January 2010 21:08
> To: Ian Bolton
> Cc: gcc@gcc.gnu.org
> Subject: Re: Possible IRA bug in assign_hard_reg
>
> Ian Bolton wrote:
> > Near the end of assign_hard_reg
Hi again,
Thanks for your answer to my other question.
I just found a case, where an allocno wasn't getting a register,
when I thought it should, since it was referenced 24 times.
I looked in setup_allocno_priorities() to see how this was used
to determine the priority and found this line:
mult
Hi Balaji.
If you have access to GCC source and are willing to change it, there is
a
way to turn off IRA (the Integrated Register Allocator) and just use
a "fast allocation" algorithm that otherwise only gets used for -O0.
Should IRA be the issue, this may be a workaround for you in the
short-ter
Hi there,
I've changed our private port of GCC to give versioned functions
better names (rather than T.0, T.1), and was wondering if there
are any existing tests that push function-versioning to the limit,
so I can test whether my naming scheme is sound.
Failing that, I'd appreciate some pointers
Message-
> From: Bingfeng Mei [mailto:b...@broadcom.com]
> Sent: 22 February 2010 09:58
> To: Ian Bolton; gcc@gcc.gnu.org
> Subject: RE: Function versioning tests?
>
> Hi,
> GCC 4.5 already contains such patch. http://gcc.gnu.org/ml/gcc-
> patches/2009-03/msg01186.html
&g
> The problem I see is that for registers 100,101 I get best register
> class D instead of R - actually they get the same cost and D is chosen
> (maybe because it is first).
Hi Frank.
Do D and R overlap? It would be useful to know which regs are in
which class, before trying to understand what i
> -Original Message-
> From: Frank Isamov [mailto:frank.isa...@gmail.com]
> Sent: 18 March 2010 14:29
> To: Ian Bolton
> Subject: Re: Coloring problem - Pass 0 for finding allocno costs
>
> On Thu, Mar 18, 2010 at 3:51 PM, Ian Bolton
> wrote:
> >> The pr
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Michael Matz
> Sent: 18 March 2010 15:13
> To: Frank Isamov
> Cc: gcc@gcc.gnu.org
> Subject: Re: Coloring problem - Pass 0 for finding allocno costs
>
> Hi,
>
> On Thu, 18 Mar 2010, Frank Isam
Hi folks!
I've moved on from register allocation (see Understanding IRA thread)
and onto scheduling.
In particular, I am investigating the effectiveness of the sched1
pass on our architecture and the associated interblock-scheduling
optimisation.
Let's start with sched1 ...
For our architectur
> > Let's start with sched1 ...
> >
> > For our architecture at least, it seems like Richard Earnshaw is
> > right that sched1 is generally bad when you are using -Os, because
> > it can increase register pressure and cause extra spill/fill code
> when
> > you move independent instructions in betwe
> > I mention all this because I was wondering which other architectures
> > have turned off sched1 for -Os? More importantly, I was wondering
> > if anyone else had considered creating some kind of clever hybrid
> > that only uses sched1 when it will increase performance without
> > increasing re
> Enabling BB-reorder only if profile info is available, is not the
> right way to go. The compiler really doesn't place blocks in sane
> places without it -- and it shouldn't have to, either. For example if
> you split an edge at some point, the last thing you want to worry
> about, is where the n
Is there any reason why BB reorder has been disabled
in bb-reorder.c for -Os, such that you can't even
turn it on with -freorder-blocks?
From what I've heard on this list in recent days,
BB reorder gives good performance wins such that
most people would still want it on even if it did
increase cod
> We're not able to enable BB reordering with -Os. The behaviour is
> hard-coded via this if statement in rest_of_handle_reorder_blocks():
>
> if ((flag_reorder_blocks || flag_reorder_blocks_and_partition)
> /* Don't reorder blocks when optimizing for size because extra
> jump insns may
>
Bugzilla 41004 calls for a more -Os-friendly algorithm for BB Reorder,
and I'm hoping I can meet this challenge. But I need your help!
If you have any existing ideas or thoughts that could help me get
closer to a sensible heuristic sooner, then please post them to this
list.
In the mean time, he
I am in the process of fixing PR44328
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328)
The problem is that gen_inbound_check in tree-switch-conversion.c subtracts
info.range_min from info.index_expr, which can cause the MIN and MAX values
for info.index_expr to become invalid.
For example:
t
Phung Nguyen wrote:
> I am trying to build cross compiler for xc16x. I built successfully
> binutils 2.18; gcc 4.0 and newlib 1.18. Everything is fine when
> compiling a simple C file without any library call. It is also fine
> when making a simple call to printf like printf("Hello world").
> Howev
Hi there,
I see in common.opt that fp-contract=fast is the default for GCC.
But then it gets disabled in c-family/c-opts.c if you are using ISO C
(e.g. with -std=c99).
But surely if you have also specified -funsafe-math-optimizations then
it should flip it back onto fast?
I see in gcc/opts.c th
> -Original Message-
> From: Joseph S. Myers
> On Thu, 6 Mar 2014, Ian Bolton wrote:
>
> > I see in common.opt that fp-contract=fast is the default for GCC.
> >
> > But then it gets disabled in c-family/c-opts.c if you are using ISO C
> > (e.g. with
> Thanks for the feedback, Joseph.
>
> I've been working on the patch, but I see in gcc/opts.c that there is
> a definite distinction between set_fast_math_flags and
> set_unsafe_math_optimizations_flags. I'm thinking this is more of a
> fast-math thing than an unsafe_math_optimizations thing, so
46 matches
Mail list logo
