On 08/13/2018 03:13 AM, Jonathan Wakely wrote:
On Sun, 12 Aug 2018 at 15:59, zerons wrote:
Should gcc give it an error to prevent a structure from converting to
char* in functions printf/fprintf?
Your question is inappropriate on this mailing list, please use
gcc-help next time. See https:/
On Sun, 12 Aug 2018 at 15:59, zerons wrote:
> Should gcc give it an error to prevent a structure from converting to
> char* in functions printf/fprintf?
Your question is inappropriate on this mailing list, please use
gcc-help next time. See https://gcc.gnu.org/lists.html
Did you try compiling wit
On Wed, 1 Aug 2018 at 01:32, Bramandia Ramadhana wrote:
>
> Hi,
>
> I am reading the gcc wiki page about atomic Acquire/Release memory
> model: https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync.
>
> It is mentioned:
>
> "Both of these asserts can pass since there is no ordering imposed
> between th
On Fri, Dec 18, 2015 at 10:40:10PM +, Eric Christopher wrote:
> > >> Without -gsplit-dwarf, there is only one .debug_macro section.
> > >>
> > >
> > > Well, that's fascinating. My guess is something in objcopy is mangling.
> >
> > I did some digging last week. It seemed to me that each block of
On Fri, Dec 18, 2015 at 2:22 PM, Eric Christopher wrote:
>
>
> On Fri, Dec 18, 2015 at 2:20 PM Siva Chandra wrote:
>>
>> On Fri, Dec 18, 2015 at 2:17 PM, Eric Christopher
>> wrote:
>> > Does the object file without -gsplit-dwarf have multiple sections? If
>> > so,
>> > that should narrow it down
On Fri, Dec 18, 2015 at 2:17 PM, Eric Christopher wrote:
> Does the object file without -gsplit-dwarf have multiple sections? If so,
> that should narrow it down for you, otherwise it's really curious.
Without -gsplit-dwarf, there is only one .debug_macro section.
> On Fri, Dec 11, 2015 at 10:33
On 12/10/14 02:02, Ajit Kumar Agarwal wrote:
Right. After IRA was complete, I'd walk over the unallocated
allocnos and split their ranges at EBB boundaries. That created
new allocnos with a smaller ??>>conflict set and reduced the
conflict set for the original unallocated allocnos.
Jeff: In t
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jeff Law
Sent: Tuesday, December 09, 2014 11:26 PM
To: Vladimir Makarov; lin zuojian; gcc@gcc.gnu.org
Subject: Re: A Question About LRA/reload
On 12/09/14 10:10, Vladimir Makarov wrote:
> gener
Thanks Vladimir & Jeff & Kugan. Combining the replies I get a better
view of RA problem.
--
Lin Zuojian
On Tue, Dec 09, 2014 at 12:10:29PM -0500, Vladimir Makarov wrote:
> On 12/09/2014 04:37 AM, lin zuojian wrote:
> > Hi,
> > I have read ira/lra code for a while, but still fails to understand
On 12/09/14 14:48, shmeel gutl wrote:
On 09-Dec-14 07:56 PM, Jeff Law wrote:
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvem
On 09-Dec-14 07:56 PM, Jeff Law wrote:
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvements on x86).
Right. After IRA was com
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvements on x86).
Right. After IRA was complete, I'd walk over the unallocated all
On 12/09/2014 04:37 AM, lin zuojian wrote:
> Hi,
> I have read ira/lra code for a while, but still fails to understand
> their relationship. The main question is why ira do color so early?
> lra pass will do the assignment anyway. Sorry if I mess up coloring
> and hard register assi
On 09/12/14 21:14, lin zuojian wrote:
> Hi Kugan,
> I have read these pdfs. My question is LRA will change the insns, so
> why brother do the coloring so early. Changing the insns can
> generates new pseudo registers, so they needs to re-assign. Is that
> correct?
Hi,
IRA's job he
Moreover, LRA assignment does not refer to the assignment result of ira
directly. In find_hard_regno_for, the value of hard_regno comes from
ira_class_hard_regs[rclass][i] with least cost.
On Tue, Dec 09, 2014 at 06:14:29PM +0800, lin zuojian wrote:
> Hi Kugan,
> I have read these pdfs. My qu
Hi Kugan,
I have read these pdfs. My question is LRA will change the insns, so
why brother do the coloring so early. Changing the insns can
generates new pseudo registers, so they needs to re-assign. Is that
correct?
--
Thanks Kugan
On Tue, Dec 09, 2014 at 09:08:46PM +1100, Kugan w
On 09/12/14 20:37, lin zuojian wrote:
> Hi,
> I have read ira/lra code for a while, but still fails to understand
> their relationship. The main question is why ira do color so early?
> lra pass will do the assignment anyway. Sorry if I mess up coloring
> and hard register assignmen
On Mon, Nov 5, 2012 at 10:13 PM, Kenneth Zadeck
wrote:
> On 11/05/2012 03:37 PM, Joseph S. Myers wrote:
>>
>> On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
>>
>>> This switch to doing math within the precision causes many test cases to
>>> behave differently. However, I want to know if differently m
On 11/05/2012 03:37 PM, Joseph S. Myers wrote:
On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
This switch to doing math within the precision causes many test cases to
behave differently. However, I want to know if differently means
"incorrectly" or "I have fixed problems that we have just decided
On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
> This switch to doing math within the precision causes many test cases to
> behave differently. However, I want to know if differently means
> "incorrectly" or "I have fixed problems that we have just decided to live
> with".
As far as I know, the TREE
On 11/05/2012 01:08 PM, Ian Lance Taylor wrote:
On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck
wrote:
The question is why is having a case label of 256 on a unsigned char switch
legal?
Are you asking why it is valid in the C language? Or are you asking
why it is valid in GIMPLE? I guess th
On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck
wrote:
>
> The question is why is having a case label of 256 on a unsigned char switch
> legal?
Are you asking why it is valid in the C language? Or are you asking
why it is valid in GIMPLE? I guess the first question is fairly
obvious so you are
On Tue, May 22, 2012 at 8:04 PM, Jiangning Liu wrote:
> Richard,
>
> But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I
> would have to modify xxx-protos.h for all back-ends.
As far as I can tell it is exposed already to the middle-end via that
hook in that you should be ab
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 22, 2012 6:36 PM
> To: Jiangning Liu
> Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org
> Subject: Re: A question about loop ivopt
>
> On Tue, May 22, 2012 at
On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, May 15, 2012 10:17 PM
>> To: Zdenek Dvorak
>> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 15, 2012 10:17 PM
> To: Zdenek Dvorak
> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu
> Subject: Re: A question about loop ivopt
>
> On Tue, May 15, 2012 a
On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak wrote:
> Hi,
>
>> > > > Why can't we replace function force_expr_to_var_cost directly with
>> function
>> > > > computation_cost in tree-ssa-loop-ivopt.c?
>> > > >
>> > > > Actually I think it is inaccurate for the current recursive algorithm
>> in
>>
Hi,
> > > > Why can't we replace function force_expr_to_var_cost directly with
> function
> > > > computation_cost in tree-ssa-loop-ivopt.c?
> > > >
> > > > Actually I think it is inaccurate for the current recursive algorithm
> in
> > > > force_expr_to_var_cost to estimate expr cost. Instead
> co
Hi,
> > Why can't we replace function force_expr_to_var_cost directly with function
> > computation_cost in tree-ssa-loop-ivopt.c?
> >
> > Actually I think it is inaccurate for the current recursive algorithm in
> > force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
> > cou
On Tue, May 15, 2012 at 7:05 AM, Jiangning Liu wrote:
> Hi,
>
> Why can't we replace function force_expr_to_var_cost directly with function
> computation_cost in tree-ssa-loop-ivopt.c?
>
> Actually I think it is inaccurate for the current recursive algorithm in
> force_expr_to_var_cost to estimate
On Tue, 2012-02-28 at 11:52 -0600, William J. Schmidt wrote:
> On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote:
>
> > I think this is probably a problem with how cprop_into_successor_phis
> > works. It only propagates into immediate successors of a block. In
> > this case copies ar
On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote:
> I think this is probably a problem with how cprop_into_successor_phis
> works. It only propagates into immediate successors of a block. In
> this case copies are propagated from bb12 into phis in bb13 and bb14 (of
> which there are n
Liu; 'William J. Schmidt'
> >> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> >> Subject: RE: A question about redundant PHI expression stmt
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: gcc-ow...@gcc.gnu.or
On Tue, Feb 28, 2012 at 9:33 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jiangning Liu
>> Sent: Tuesday, February 28, 2012 4:07 PM
>> To: Jiangning Liu; 'William J. Schmidt'
>> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> -Original Message-
> From: Jiangning Liu
> Sent: Tuesday, February 28, 2012 4:07 PM
> To: Jiangning Liu; 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question about redundant PHI expression stmt
>
>
>
> &g
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, February 28, 2012 11:19 AM
> To: 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question abou
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> William J. Schmidt
> Sent: Monday, February 27, 2012 11:32 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: Re: A question about redundan
On Fri, 2012-02-24 at 16:07 +0800, Jiangning Liu wrote:
> Hi,
>
> For the small case below, there are some redundant PHI expression stmt
> generated, and finally cause back-end generates redundant copy instructions
> due to some reasons around IRA.
>
> int *l, *r, *g;
> void test_func(int n)
> {
On Fri, Feb 24, 2012 at 9:07 AM, Jiangning Liu wrote:
> Hi,
>
> For the small case below, there are some redundant PHI expression stmt
> generated, and finally cause back-end generates redundant copy instructions
> due to some reasons around IRA.
>
> int *l, *r, *g;
> void test_func(int n)
> {
>
On Fri, Nov 18, 2011 at 2:07 AM, Yuehai Du wrote:
> 2011/11/18 Richard Guenther :
>> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du wrote:
>>> 2011/11/17 Richard Guenther :
On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou
wrote:
>> Huh, IVOPTs should never cause a different size memory
2011/11/18 Richard Guenther :
> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du wrote:
>> 2011/11/17 Richard Guenther :
>>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou
>>> wrote:
> Huh, IVOPTs should never cause a different size memory read. I wonder
> if the original issue would still r
On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou wrote:
>> Huh, IVOPTs should never cause a different size memory read. I wonder
>> if the original issue would still reproduce with the fix reverted.
>
> The original issue was unaligned arrays in packed structures. I don't see
> what
> could have
Hi,
On Wed, 16 Nov 2011, Jeff Law wrote:
> Right. In theory, path isolation would make this optimizable. Make a
> copy of the block containing a[x] = 2 and make it the target when x !=
> 100. At the source level it'd look something like this:
>
> int x;
> extern void f(void);
>
> void g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/11 04:00, Richard Guenther wrote:
> On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu
> wrote:
>> Hi,
>>
>> For this test case,
>>
>> int x; extern void f(void);
>>
>> void g(int *a) { a[x] = 1; if (x == 100) f(); a[x] = 2; }
>>
>> For trunk
Hi,
On Wed, 16 Nov 2011, Eric Botcazou wrote:
> > f() may change the value of x, so you cannot optimize away the load on that
> > execution path.
>
> This looks more like an aliasing issue with a, doesn't it?
Correct. There's no call to f() between a[x] and x==100, but the store to
a[x] might
> f() may change the value of x, so you cannot optimize away the load on that
> execution path.
This looks more like an aliasing issue with a, doesn't it?
--
Eric Botcazou
> Huh, IVOPTs should never cause a different size memory read. I wonder
> if the original issue would still reproduce with the fix reverted.
The original issue was unaligned arrays in packed structures. I don't see what
could have changed since then.
--
Eric Botcazou
On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu wrote:
> Hi,
>
> For this test case,
>
> int x;
> extern void f(void);
>
> void g(int *a)
> {
> a[x] = 1;
> if (x == 100)
> f();
> a[x] = 2;
> }
>
> For trunk, the x86 assembly code is like below,
>
> movl
On Mon, Nov 14, 2011 at 4:58 AM, Yuehai Du wrote:
> Hi
>
> i found IVOPTS didn't work well on some case if the loop contain
> some unaligned access. it didn't take this kind of memory access into
> account because this check in function:find_interesting_uses_address
>
> /* Moreover, on stric
From tree dump we can see that there are two assignments from x, one
to unsigned and one to signed. I guess that's the reason. Apparently
there is room to improve though.
int prephitmp.8;
int * D.2027;
unsigned int D.2026;
unsigned int x.1;
int x.0;
# BLOCK 2 freq:1
# PRED: ENTR
> 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
On Monday 26 September 2011, Matthew Gretton-Dann wrote:
> As far as I understand it -Warray-bounds should be emitting a warning
> for this case, but PR31227 seemed to be about removing these warnings.
>
> The PR comments do not explain why the array accesses are valid and I'm
> hoping someone ca
On 26/09/11 10:03, Jonathan Wakely wrote:
On 26 September 2011 08:13, Jiangning Liu wrote:
PING...
-Original Message-
From: Jiangning Liu [mailto:jiangning@arm.com]
Sent: Thursday, September 22, 2011 10:19 AM
To: gcc@gcc.gnu.org
Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue
On 26 September 2011 08:13, Jiangning Liu wrote:
> PING...
>
>> -Original Message-
>> From: Jiangning Liu [mailto:jiangning@arm.com]
>> Sent: Thursday, September 22, 2011 10:19 AM
>> To: gcc@gcc.gnu.org
>> Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
>> Matthew
PING...
> -Original Message-
> From: Jiangning Liu [mailto:jiangning@arm.com]
> Sent: Thursday, September 22, 2011 10:19 AM
> To: gcc@gcc.gnu.org
> Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
> Matthew Gretton-Dann
> Subject: A question about detecting array
>AFAIK SMS will not do speculative memory access.
Right, SMS does no speculative memory access. Though that might not be
a bad idea...
Ayal.
2011/8/11 Revital Eres
>
> Hello,
>
> >> I appriciate explanation regarding the following piece of code in
> >> sched_analyze_insn function (sched-deps.c)
Hello,
>> I appriciate explanation regarding the following piece of code in
>> sched_analyze_insn function (sched-deps.c): When handling jump instruction
>> dependence edges are created between the jump instruction and memory
>> writes and volatile reads and I'm not quite sure the reason why.
>
>
Revital Eres writes:
> I appriciate explanation regarding the following piece of code in
> sched_analyze_insn function (sched-deps.c): When handling jump instruction
> dependence edges are created between the jump instruction and memory
> writes and volatile reads and I'm not quite sure the reaso
Hi,
On Sat, 26 Mar 2011, Levon Haykazyan wrote:
> I was trying to configure vim to work better with gcc coding
> conventions. When I set 'tab' symbol to be interpreted as 2 spaces, I
> noticed that a lot of formatting in e.g. gcc/cp/parser.c was gone.
Yeah, never change tabstop, change shiftwi
On Fri, 12 Nov 2010, Joern Rennecke wrote:
Please read the node "Register Classes" in doc/tm.texi .
I am sorry , could you please highlight the relevant portion for me?
In the pattern that i have given the combination (a,W) satisfies the
pattern. But its not matched because i have given then lik
0:37
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: RE: A question about using restrict
>
> Hello Bingfeng,
>
> Thanks for your reply! I would be very interested to try your patch.
>
> Revital
>
>
>
>
> From: "Bingfeng Mei"
> To: Revital
Hello Bingfeng,
Thanks for your reply! I would be very interested to try your patch.
Revital
From: "Bingfeng Mei"
To: Revital1 Eres/Haifa/i...@ibmil, "gcc@gcc.gnu.org"
Date: 13/12/2010 12:20 PM
Subject: RE: A question about using restrict
Hi, Revital,
Sorry for late reply. I think you can write following code
according to C99 standard to make sure src1/src2 don't alias
with dst. However, current GCC support for restrict is still
quite weak. The restrict info tends to be lost in all optimizations,
especially ivopts. You won't get the
Quoting Dave Korn :
Had a good look through and still couldn't find it, would you mind
giving me
a pointer to where should I start reading?
reload.c line 4094 (as of revision 18)
On 12/11/2010 16:06, Joern Rennecke wrote:
> Quoting Dave Korn:
>
>> Is that documented anywhere? I couldn't find it in the constraints
>> chapters of the internals manual.
>
> It's in the reload source code...
Had a good look through and still couldn't find it, would you mind giving me
a poi
Quoting Dave Korn :
Is that documented anywhere? I couldn't find it in the
constraints chapters
of the internals manual.
It's in the reload source code...
And there are subtle register priority implications of having merged or
separate alternatives.
Sorry, is this separate from the
On 12/11/2010 15:32, Joern Rennecke wrote:
> Quoting Dave Korn :
>
>> By "combine constraints", you mean "Omit all the commas between
>> alternatives, mash them together in a single string, and expect GCC
>> to permute
>> all the possible combinations"?
>>
>> I didn't know that was possible a
Quoting Dave Korn :
By "combine constraints", you mean "Omit all the commas between
alternatives, mash them together in a single string, and expect GCC
to permute
all the possible combinations"?
I didn't know that was possible at all. I thought GCC would
interpret those
as multi-le
On 12/11/2010 12:51, Mohamed Shafi wrote:
> All the constraints are one letter constraints for my target. Here 'W'
> is for symbol_ref and all others are register constraints. So for a
> particular combination when operand 0 is 'a' and operand 1 is 'W' i
> got the following ICE :
> I get this ICE
Quoting Mohamed Shafi :
On 12 November 2010 18:39, Joern Rennecke wrote:
Quoting Mohamed Shafi :
So i have the following questions:
1. Why is that constraints are not matched here?
Please read the node "Register Classes" in doc/tm.texi .
I am sorry , could you please highlight the rele
On 12 November 2010 18:39, Joern Rennecke wrote:
> Quoting Mohamed Shafi :
>
>> So i have the following questions:
>>
>> 1. Why is that constraints are not matched here?
>
> Please read the node "Register Classes" in doc/tm.texi .
>
I am sorry , could you please highlight the relevant portion for
Quoting Mohamed Shafi :
So i have the following questions:
1. Why is that constraints are not matched here?
Please read the node "Register Classes" in doc/tm.texi .
On Mon, Aug 23, 2010 at 02:46:21PM +0300, Revital1 Eres wrote:
> I'm compiling the following test with GCC 4.6.0 and I do not see that
> MAX_EXPR is generated for (num)<0)?0:(num).
> With GCC 4.3.2 it is generated OK in original dump (both compilation were
> made with -O3). Is there a flag I shoul
On Mon, 26 Jul 2010, Revital1 Eres wrote:
>
> Hello,
>
> Doloop optimization fails to be applied on the following kernel from
> tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
> iteration
> case' message; taken from the loop2_doloop dump. (please see below).
> With an older
On 07/13/2010 12:20 PM, Mingming Sun wrote:
On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote:
On 07/13/2010 11:56 AM, Mingming Sun wrote:
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E&2F.
My patch is based on Gcc4.4.0.
If I want to submit my pat
Do you mean I must submit it to the main brach?
On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote:
> On 07/13/2010 11:56 AM, Mingming Sun wrote:
>>
>> Hi,
>>
>> I want to submit a patch about loongson 3A, a new architecture
>> different from loongson 2E& 2F.
>> My patch is based on Gcc4.4.0.
>>
On 07/13/2010 11:56 AM, Mingming Sun wrote:
Hi,
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E& 2F.
My patch is based on Gcc4.4.0.
If I want to submit my patch, which branch shoud I submit to, gcc4.4.0
branch or I should change the patch to
suite with
On Thu, 2010-06-24 at 08:57 -0600, Jeff Law wrote:
> On 06/24/10 02:02, Revital1 Eres wrote:
> > Hello,
> >
> > In the new target I'm working on there are branch regs and gprs.
> > The loads and store instructions are only to/from the gprs, so if a
> > branch reg needs to be spilled it first needs
On 06/24/10 02:02, Revital1 Eres wrote:
Hello,
In the new target I'm working on there are branch regs and gprs.
The loads and store instructions are only to/from the gprs, so if a
branch reg needs to be spilled it first needs to be moved to a gpr and
then stored to memory. I've implemented mov
Thank you Ian Lance Taylor. Your reply helps me a lot :)
Ling Kun
On Tue, May 25, 2010 at 1:10 PM, Ian Lance Taylor wrote:
> Ling Kun writes:
>
>> when deeply looking into the libgcc.a of
>> mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
>> _udivdi3.o. but when objdump this obje
Ling Kun writes:
> when deeply looking into the libgcc.a of
> mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
> _udivdi3.o. but when objdump this object file, no entry for function
> _udivdi3 is found, only a __udivti3 function entry, and there are also
> some other *di3.o file whi
On Tue, 11 May 2010, Revital1 Eres wrote:
>
> Hello,
>
> I have a question regarding the process of bundling and NOPs insertion for
> VLIW architecture
> and I appreciate your answer:
>
> I am calling the second scheduler from the machine reorg pass; similar to
> what is done for IA64.
> I no
"Alexei I. Adamovich" writes:
> I have a question concerning GGC and gengtype in particular.
> The question is: can I have DIFFERENT <>-ed types and
> variables with the SAME NAMES in two DIFFERENT front ends?
Yes.
Needless to say, I don't recommend it. What you describe sounds like
a recipe f
2009/12/17 Zdenek Dvorak :
> Hi,
>
>> > Is there a way to pass to the unroller the maximum number of iterations
>> > of the loop such that it can decide to avoid unrolling if
>> > the maximum number is small.
>> >
>> > To be more specific, I am referring to the following case:
>> > After the vecto
Hi,
> > Is there a way to pass to the unroller the maximum number of iterations
> > of the loop such that it can decide to avoid unrolling if
> > the maximum number is small.
> >
> > To be more specific, I am referring to the following case:
> > After the vectorizer decides to peel for alignment
On Thu, Dec 17, 2009 at 1:07 PM, Revital1 Eres wrote:
>
> Hello,
>
> Is there a way to pass to the unroller the maximum number of iterations
> of the loop such that it can decide to avoid unrolling if
> the maximum number is small.
>
> To be more specific, I am referring to the following case:
>
Hi, Ian,
Thank you for the information about register allocation sequence.
My problem was solved by adding AP-to-FP entry to ELIMINABLE_REGS.
I also encountered another minor problem. When GCC tries to generate a
"push SP" instruction (e.g. some_func(&the_only_local_var);), it is
detecte
Ivan Shcherbakov writes:
> For i386-gcc, this seems to happen during global register allocation
> pass. This corresponds to IRA pass of gcc 4.4.x. I have attached the
> corresponding RTL dump files.
That means that reload is where the register is eliminated, as
expected. Reload is really pa
Hi, Ian,
For i386-gcc, this seems to happen during global register allocation
pass. This corresponds to IRA pass of gcc 4.4.x. I have attached the
corresponding RTL dump files.
--
Best regards,
Ivan Shcherbakov mailto:shcherba...@eit.uni-kl.de
TU Kaiserslautern, German
Ivan Shcherbakov writes:
> It seems that in x86 the argp register gets
> eliminated before the reload phase.
That seems unlikely to me. What pass do you think is eliminating the
argument register?
Ian
Hi, Ian,
I have created a simpler example, just a function computing a sum of
its arguments:
int sum(int a, int b, int c, int d, int e, int f, int g, int h)
{
return a + b + c + d + e + f + g + h;
}
The "argp" is a pseudo-register included in all register classes, that
contain normal
Ivan Shcherbakov writes:
> ELIMINATE_REGS and TARGET_CAN_ELIMINATE are set correctly. As far as I
> understand from further investigation, at some point during
> compilation, the argument pointer register is used, then the
> expand_prologue() produces INSNs including "push
Hi, Ian,
ELIMINATE_REGS and TARGET_CAN_ELIMINATE are set correctly. As far as I
understand from further investigation, at some point during
compilation, the argument pointer register is used, then the
expand_prologue() produces INSNs including "push argp" (as "argp" is
pres
Ivan Shcherbakov writes:
> I have noticed that the latest ports of GCC (e.g. i386) use a
> pseudo-register (argp in i386) defined as fixed in FIXED_REGISTERS.
> When I implement it similarly in msp430 port (instead of hardware
> register r5, add a pseudo-register marked as fi
Eric Botcazou wrote:
> Patch attached. I'll give it a whirl on SPARC but not immediately so, Kaz,
> if
> you can test it on SH in the meantime, you can apply it on all branches.
>
>
> 2009-07-14 Eric Botcazou
>
> PR rtl-optimization/40710
> * resource.c (mark_target_live_regs)
> > Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes?
>
> The same question arises to me.
That's explained in the head comment of find_basic_block: the CFG is destroyed
by the DBR pass in some controlled way so the strategy is to recompute the
liveness info starting from data that ar
Steven Bosscher wrote:
On Mon, Jul 13, 2009 at 11:46 PM, Kaz Kojima wrote:
Hi,
I hope DF/middle-end experts will comment about this.
PR target/40710
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710
is a wrong code problem on SH. A delayed slot of a conditional
branch insn is wrongly fill
Steven Bosscher wrote:
> OK, so isn't the bug obvious then? You said: "mark_target_live_regs
> uses df_get_live_in to get live regs for the basic block including the
> opposite_thread insn which is insn 32.". And you had insn 32 in basic
> block 3. So find_basic_block returns the wrong basic block
> I doubt he can help you with this one... When your problem concerns
> reorg, you should talk to people like Eric Botcazou or Richard
> Sandiford or HP Nillson. I've added Eric to the CC, to make this a
> happier crowd. :-)
Thank you. I was about to leave for vacation but I'll stay for this on
On Tue, Jul 14, 2009 at 1:17 AM, Kaz Kojima wrote:
> [I'd like to add kenny to the CC list.]
I doubt he can help you with this one... When your problem concerns
reorg, you should talk to people like Eric Botcazou or Richard
Sandiford or HP Nillson. I've added Eric to the CC, to make this a
happi
1 - 100 of 192 matches
Mail list logo
