Hi Guys,
All I wanted to do was to make GCC's ARM assembler output slightly
easier to read...
I would like to propose a patch to create a new header file in the
include/ directory. This file would contain enums describing the
attributes that be can found in SHT_GNU_ATTRIBUTES sections.
On 29 Sep 2011, at 10:34, "Nick Clifton" wrote:
> Hi Guys,
>
> All I wanted to do was to make GCC's ARM assembler output slightly
> easier to read...
>
> I would like to propose a patch to create a new header file in the
> include/ directory. This file would contain enums describing the
>
On Tue, Sep 27, 2011 at 4:19 PM, Amker.Cheng wrote:
> Hi,
> I ran into a case and found conditional (const) propagation is
> mishandled in cprop pass.
> With following insn sequence after cprop1 pass:
>
> (note 878 877 880 96 [bb 96] NOTE_INSN_B
Hello,
the GCC 4.6.2 seems to be ready soon. It would be very nice if some ARM bugs
can be fixed for this release (in the GCC 4.6-20110923 snapshot they are not
fixed).
1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641
Here we have a test case and a fix.
2. http://gcc.gnu.org/bugzilla/s
"Amker.Cheng" writes:
> (insn 882 881 883 96 (set (reg:CC 24 cc)
> (compare:CC (reg:SI 684 [ default_num_contexts ])
> (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
> (nil))
>
>
> The insn49 should be propagated with conditional const from insn882
> and jump_i
Hi Richard,
I don't think it's a good idea to have the attributes of
every CPU we support in a single file. That's going to
get unmaintainable very quickly.
Really - why ?
These attributes are mostly static. Some new ones might be added from
time to time, but baring the introduction of new
> Unless there's something arch specific related to arm, insn 882 is a
> compare, which won't change r684. Why do you think 0 should
> propagated to r291 if r684 is not zero?
>
Thanks for replying.
Sorry if I misunderstood anything below, and please correct me.
insn 882 : cc <- compare (
> insn 882 : cc <- compare (r684, 0)
> jump_insn 883 : if (cc != 0) goto insn 46
> insn 49: r291 <- r684
> ..
> insn 46
>
> cc contains the result of subtracting 0 from r684; control flow goes to
> insn_49 only if (cc == 0), which implies (r684 == 0).
> Then at insn_49 we
On 09/29/11 16:43, Rahul Kharche wrote:
>
>> insn 882 : cc <- compare (r684, 0)
>> jump_insn 883 : if (cc != 0) goto insn 46
>> insn 49: r291 <- r684
>> ..
>> insn 46
>>
>> cc contains the result of subtracting 0 from r684; control flow goes to
>> insn_49 only if (cc == 0)
On Thu, 29 Sep 2011, Nick Clifton wrote:
> Hi Richard,
>
> > I don't think it's a good idea to have the attributes of
> > every CPU we support in a single file. That's going to
> > get unmaintainable very quickly.
>
> Really - why ?
>
> These attributes are mostly static. Some new ones might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 09:26, Bernd Schmidt wrote:
> On 09/29/11 16:43, Rahul Kharche wrote:
>>
>>> insn 882 : cc <- compare (r684, 0) jump_insn 883 : if
>>> (cc != 0) goto insn 46 insn 49: r291 <- r684
>>> .. insn 46
>>>
>>> cc contai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 08:43, Rahul Kharche wrote:
>
>> insn 882 : cc <- compare (r684, 0) jump_insn 883 : if
>> (cc != 0) goto insn 46 insn 49: r291 <- r684 ..
>> insn 46
>>
>> cc contains the result of subtracting 0 from r684; contro
On 09/29/11 17:36, Jeff Law wrote:
> On 09/29/11 09:26, Bernd Schmidt wrote:
>> ISTR cse.c has some support for this.
> cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Bernd
> On 09/29/11 17:36, Jeff Law wrote:
> > On 09/29/11 09:26, Bernd Schmidt wrote:
> >> ISTR cse.c has some support for this.
> > cprop.c -- see references to implicit_sets.
>
> cse too: record_jump_equiv.
Interesting. Are the two approaches subtly different
or do they apply precisely the same pred
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/11 09:48, Rahul Kharche wrote:
>> On 09/29/11 17:36, Jeff Law wrote:
>>> On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
>>> cprop.c -- see references to implicit_sets.
>>
>> cse too: record_jump_equiv.
>
>
"Amker.Cheng" writes:
>
> Thanks for replying.
> Sorry if I misunderstood anything below, and please correct me.
>
> insn 882 : cc <- compare (r684, 0)
> jump_insn 883 : if (cc != 0) goto insn 46
> insn 49: r291 <- r684
> ..
> insn 46
>
> cc contains the result of subtract
I've had no success lately getting GCC to bootstrap successfully. My
last successful bootstrap was on September 6; my builds on September
7 through today all end with a comparison failure. Here's the end
of my build log:
gmake[2]: Entering directory `/export/home/arth/src/gcc-0929'
gmake[3]: Ente
Snapshot gcc-4.5-20110929 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110929/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
>
> Nobody mentioned this so I might be way off but cc doesn't get (minus
> (reg r684) (const_int 0)). It gets the `condition codes` modification as
> a consequence of the subtraction.
>
Hi Paulo,
According to section "comparison operations" in internal:
"The comparison operators may be used to co
As some of you might know, I have been researching and working on a region-based
memory management plugin for GCC. My target is specifically the Go language.
With that said, I have been making a fair amount of progress. More recently, I
have been benchmarking my work, and it came to my attention
>>
>> I believe, the optimization you may be referring to is value range
>> propagation which does predication of values based on predicates of
>> conditions. GCC definitely applies VRP at the tree stage, I am not
>> sure if there is an RTL pass to do the same.
> There are also RTL optimizers which
Matt Davis writes:
> As some of you might know, I have been researching and working on a
> region-based
> memory management plugin for GCC. My target is specifically the Go language.
> With that said, I have been making a fair amount of progress. More recently,
> I
> have been benchmarking my
22 matches
Mail list logo
