We are experimenting on the custom sparc-based core for embedded applications.
The big headache that I am facing these days is that "-mcpu=v8"(gcc-sparc-v8)
does not support little-endian. After web searching, it seems that
gcc-sparclet supported V8 engine but it seems that it's now deleted(?).
On Mon, Mar 25, 2013 at 7:20 PM, Tom Tromey wrote:
>> "Lawrence" == Lawrence Crowl writes:
>
> Lawrence> Hm. I haven't thought about this deeply, but I think SFINAE may
> Lawrence> not be less of an issue because it serves to remove candidates
> Lawrence> from potential instantiation, and gd
On Mon, Mar 25, 2013 at 10:23 PM, Dinar Temirbulatov
wrote:
> Hi,
> We noticed some performance gains if we are not using jump over some
> simple switch statements. Here is the idea: Check whether the switch
> statement can be expanded with conditional instructions. In that case
> jump tables shou
On Tue, Mar 26, 2013 at 10:31 AM, Richard Biener wrote:
> On Mon, Mar 25, 2013 at 10:23 PM, Dinar Temirbulatov wrote:
>> The error in 252.eon was due to incorrect setup. Also "if (count >
>> 3*PARAM_VALUE (PARAM_SWITCH_JUMP_TABLES_BB_OPS_LIMIT))" does not look
>> correct, and probably it is better
> Yes, the binary size is 8-10% smaller. Unfortunately there are no performance
> improvements.
>
> LTO+PGO-disable-plugin:
> -rwxr-xr-x 1 markus markus 15025568 Mar 25 15:49 cc1
> -rwxr-xr-x 1 markus markus 16198584 Mar 25 15:49 cc1plus
> -rwxr-xr-x 1 markus markus 13907328 Mar 25 15:49 lto1
> -r
-Ursprüngliche Nachricht-
Gesendet: Dienstag, 26 März 2013 um 12:13:26 Uhr
Von: "Jan Hubicka"
An: "Markus Trippelsdorf"
Betreff: Re: Compiler speed (vanilla vs. LTO, PGO and LTO+PGO)
> Yes, the binary size is 8-10% smaller. Unfortunately there are no performance
> improvements.
>
> LTO+PG
Hi, sorry for the delay of this reply but just returned from paternity leave.
>
> Have you had a look at the SH backend? SH cores have a "T Bit"
> register, which functions as carry bit, over/underflow, comparison
> result and branch condition register. In the SH backend it's treated as
> a fix
Hi, sorry for the delay of this reply but just returned from paternity leave.
> -Original Message-
> From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
> Sent: 05 March 2013 01:45
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Modeling predicate registers with more than one bit
>
Hi everyone,
While working with some splitters I noticed that the RTL optimisation
passes do not optimise away a no-op wrapped in a cond_exec.
So for example, if my splitter generates something like:
(cond_exec (lt:SI (reg:CC CC_REGNUM) (const_int 0))
(set (match_dup 1)
I was playing with adding support of the various modes of widening
multiplies on my backend, and hit some restrictions in the expansion
code that I couldn't explain to myself. These restrictions only impact
the signed by unsigned version.
The first limitation was about the detection of widening mu
On Tue, 26 Mar 2013, Paulo Matos wrote:
> > -Original Message-
> > From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
> > Sent: 05 March 2013 01:45
> > To: Paulo Matos
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: Modeling predicate registers with more than one bit
> >
> > Except for CCmodes be
While working on having the divisions by constants optimized by my GCC
targeting, I realized that whatever *muldi3_highpart my backend
provides, it would never be used because of the bounds checks that
expmed.c does on the cost arrays. For example:
choose_multiplier (abs_d, size, size - 1,
Hello everyone,
I am trying to clone a git repository and I am getting the following
error. Can someone please tell me what this error could be and how I could fix
this? It worked for me a while back but not now.
I tried the following command:
git clone http://gcc.gnu.org/git/gcc.git gcc
On 2013.03.26 at 18:28 +, Iyer, Balaji V wrote:
> Hello everyone,
> I am trying to clone a git repository and I am getting the following
> error. Can someone please tell me what this error could be and how I could
> fix this? It worked for me a while back but not now.
>
> I tried the f
Richard> Did you consider using clang?
Richard>
We may look at it after re-examining g++.
I think there are some reasons to prefer gcc.
Tom
On Tue, Mar 26, 2013 at 3:02 PM, Tom Tromey wrote:
> Richard> Did you consider using clang?
> Richard>
>
> We may look at it after re-examining g++.
> I think there are some reasons to prefer gcc.
Yes, obviously :-)
-- Gaby
> -Original Message-
> From: Markus Trippelsdorf [mailto:mar...@trippelsdorf.de]
> Sent: Tuesday, March 26, 2013 3:16 PM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'; Jason Merrill (ja...@redhat.com)
> Subject: Re: GIt Issue
>
> On 2013.03.26 at 18:28 +, Iyer, Balaji V wrote:
> > Hel
On 3/25/13, Tom Tromey wrote:
> I think the intro text of this message provides the best summary
> of the approach:
>
> http://sourceware.org/ml/gdb-patches/2010-07/msg00284.html
Are the symbol searches specific to the scope context, or does it
search all globally defined symbols?
If you recreat
> The big headache that I am facing these days is that
> "-mcpu=v8"(gcc-sparc-v8 does not support little-endian. After web
> searching, it seems that gcc-sparclet supported V8 engine but it seems that
> it's now deleted(?).
I'm not sure that SPARClet was V8. In any case, the SPARC V8 architecture
"Iyer, Balaji V" writes:
>> > I tried the following command:
>> > git clone http://gcc.gnu.org/git/gcc.git gcc.git
>>
>> Please try the git protocol instead of http:
>> git clone git://gcc.gnu.org/git/gcc.git gcc.git
>
> Thanks for your help Markus. Unfortunately, http is the only option for me.
Hello everyone,
I am trying to understand the points-to analysis ("pta") ipa pass, but
I am not able to match the information generated by the pass and that
in structure "SSA_NAME_PTR_INFO".
For the code segment,
--
int var1, var2, var3, var4, *ptr1, *
21 matches
Mail list logo
