ideas, or anything I can do to give
information or ideas,
Jc
On Fri, Jun 12, 2009 at 3:55 AM, Paolo Bonzini wrote:
> Jean Christophe Beyler wrote:
>>
>> I've gone back to this problem (since I've solved another one ;-)).
>> And I've moved forward a bit:
>>
&
./tm-preds.h:51:1: warning: "EXTRA_ADDRESS_CONSTRAINT" redefined
Any ideas why this happens when I add a constraint to my machine description?
As always, thank you very much for your time,
Jean Christophe Beyler
ficult to fix?
Thanks !
Jean Christophe Beyler
ue, Jul 14, 2009 at 3:53 PM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> In file included from ./tm_p.h:5,
>> from /home/toto/gcc-4.3.2/gcc/c-pragma.c:35:
>> ./tm-preds.h:40:1: warning: "CONSTRAINT_LEN" redefined
>> In fil
Ah ok, so I can see why it would not be able to perform that
optimization around the loop but I changed the code to simply have
this:
uint64_t foo (void)
{
return data[0] + data[1] + data[2];
}
And this generates :
la r9,data
la r7,data+8
ldd r6,0(r7)
ldd r8,0(r9)
ldd r
I agree. I've actually pretty much finished that change and it seems
to be stable. I think it will be more maintainable in the
constraints.md state than it was before,
Thanks again,
Jc
On Wed, Jul 15, 2009 at 1:30 AM, Paolo Bonzini wrote:
> On 07/14/2009 10:31 PM, Jean Christophe Beyl
sn with uid = 17.
deleting insn with uid = 17.
ending the processing of deferred insns
On Wed, Jul 15, 2009 at 12:25 PM, Adam Nemet wrote:
> Jean Christophe Beyler writes:
>> uint64_t foo (void)
>> {
>> return data[0] + data[1] + data[2];
>> }
>>
>> A
I had a similar issue on my port. I fixed it by adding a check_move
before the generation of the move to look at the potential offset
used.
That allowed the compiler to not generate those wrong offsets
depending on the mode on my port. It looks something like this :
/* Check the operands of the m
why would it change it to r3 that was
also a FIXED_REGISTER.
As always, thanks for any input,
Jean Christophe Beyler
noticed that by modifying
my constraints, I'm getting the generated code I was looking for.
Thanks again,
Jc
On Fri, Aug 21, 2009 at 8:12 PM, Richard Henderson wrote:
> On 08/21/2009 04:01 PM, Jean Christophe Beyler wrote:
>>
>> /* If we have a 0, use r0 instead */
>
> Don
:DI 3 "const_int_operand" "L")))]
"check_extract (DImode, DImode, operands[2], operands[2])"
"extr\\t%0,%1,%3,%2";
[(set_attr "type" "arith")
(set_attr "mode" "DI")
(set_attr "length" "1")])
For the moment, I haven't put anything in my expand because I don't
know if anything is necessary yet. I was first looking at if GCC was
generating the right code on simple examples.
But I get this message:
struct4.c: In function 'goo':
struct4.c:32: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4923
Does anybody know how can I solve this issue ?
Thanks again for all your help,
Jean Christophe Beyler
Sorry, you are correct. That line is the :
gcc_assert (outermode != VOIDmode);
of the simplify_subreg function.
However, I've played around with it and saw that I made a mistake when
writing up this question, I simplified what I had put in my MD file,
and actually made a mistake. I apologize.
I
On Mon, Aug 31, 2009 at 4:36 PM, Richard Henderson wrote:
> On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote:
>>
>> If I replace this :
>> (define_insn "extzv"
>> [(set (match_operand 0 "register_operand" "")
&g
On Mon, Aug 31, 2009 at 5:27 PM, Richard Henderson wrote:
> On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote:
>>
>> I am going to try this but shouldn't it be :
>>
>> (set (reg:QI new-scratch))
>> (zero_extract:DI ...))
>
> No.
Ok, I th
check the
symbol_ref to see what function is called. I can then modify the call
at that point.
My question is: is this a good approach or is there another solution
that you would use?
Thanks again for your time,
Jean Christophe Beyler
4 PM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> I have been also been looking into how to generate a function call for
>> certain operations. I've looked at various other targets for a similar
>> problem/solution but have not seen anything. On my targe
this instead:
mult tmp1, a, b
mult tmp2, c, d
mov output1, tmp1
mov output2, tmp2
call bar
in which case, I know I can do what I am currently doing.
Thanks again for your help and I apologize for these basic questions...
Jc
On Tue, Sep 1, 2009 at 2:30 PM, Jean Christophe
Beyler wrote:
> I h
o-registers and then moves them to the actual
output registers. It's the next phases that will combine the two to
save a move.
On Tue, Sep 1, 2009 at 6:26 PM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> First off: does this seem correct?
>
> Awkward though it
will be kept. This could be a solution to the second issue but
I'll wait to understand what you meant first.
Jc
On Tue, Sep 1, 2009 at 6:35 PM, Jean Christophe
Beyler wrote:
> I don't think I quite understand what you're meaning. I want to use
> the standard ABI, basically I want
> Yes. Though I do wonder why you are avoiding using the normal libcall
> machinery. If all you really care about is changing the function name, then
> all you need to do is modify the appropriate optab. See, for instance,
> arm_init_libfuncs.
I guess both could work. I had seen the TARGET_INIT
be correct anyway.
My theory is that reload needs the o EVEN IF what it will be trying to
do is illegal and it will figure that out and finally generate the
right thing afterwards.
Thus, why the o is necessary and not the R.
Is this correct?
Thanks,
Jean Christophe Beyler
(reg:DF 10 r10)
It is theorically possible that my code fails for integer modes but
that my code example doesn't force the compiler in the same route and
thus I don't see a fail. But I don't really think so.
Any ideas ?
Thanks a lot,
Jc
On Mon, Sep 14, 2009 at 2:16 PM, Jean Chri
> Not that I can think of. Did you provide all of the secondary reload
> stuff that you need? Probably not.
Probably not, I've been working at cleaning up what was done before.
What exactly is needed to be done to define the secondary reload stuff
?
> You'll do much better by rejecting these ad
Dear all,
I was wondering if it was possible to turn off the unrolling to
certain loops. Basically, I'd like the compiler not to consider
certain loops for unrolling but fail to see how exactly I can achieve
that.
I've traced the unrolling code to multiple places in the code (I'm
working with the
Yes, I'd be happy to look into how you did it or where you were up to.
I don't know what I'll be able to do but it might lead me in the right
direction and allow me to finish what you started.
Thanks,
Jc
On Tue, Oct 6, 2009 at 2:53 AM, Zdenek Dvorak wrote:
> Hi,
>
>> I was wondering if it was p
Dear all,
I've been working on a loop unrolling scheme and I have a few questions:
1) Is there an interest in having a loop unrolling scheme for GCC? I'm
working on the 4.3.2 version but can port it afterwards to the 4.5
version or any version you think is appropriate.
2) I was using a simple ex
Hi,
> such an epilogue is needed when the # of iterations is not known in the
> compile time; it should be fairly easy to modify the unrolling not to
> emit it when it is not necessary,
Agreed, that is why I was surprised to see this in my simple example.
It seems to me that the whole unrolling p
Ok, I've actually gone a different route. Instead of waiting for the
middle end to perform this, I've directly modified the parser stage to
unroll the loop directly there.
Basically, I take the parser of the for and modify how it adds the
various statements. Telling it to, instead of doing in the
You are entirely correct, I hadn't thought that through enough.
So I backtracked and have just merged what Bingfeng Mei has done with
your code and have now a corrected version of the loop unrolling.
What I did was directly modified tree_unroll_loop to handle the case
of a perfect unroll or not i
optimization. I still have problem in handling
> combination of unroll and ivdep.
>
> Bingfeng
>
>> -Original Message-
>> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com]
>> On Behalf Of Jean Christophe Beyler
>> Sent: 15 October 2009 16:3
Original Message-
>> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com]
>> On Behalf Of Jean Christophe Beyler
>> Sent: 15 October 2009 17:27
>> To: Bingfeng Mei
>> Cc: Zdenek Dvorak; gcc@gcc.gnu.org
>> Subject: Re: Turning off unrolling to certain
It works no problem for me.
This is what I get:
$ gcc -Wall -o "Test.exe" "macro.cpp" -lstdc++ -s -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-compiler=c --enable-language=c
--prefix=/home/beyler/tmp/gcc-4.3.2/bin
Thread model: posix
gcc version 4.3.2 (
ts correct.
Thanks for any input,
Jc
On Tue, Nov 3, 2009 at 2:01 PM, Jean Christophe Beyler
wrote:
> Dear all,
>
> I've been working on handling the Debugging information for the use of
> GDB on my port. Though I definitely know that, when compiling in -O3,
> some information
Dear all,
I've been working on handling the Debugging information for the use of
GDB on my port. Though I definitely know that, when compiling in -O3,
some information is lost and the debugger can't always have all the
information, I'd like to at least keep the values of the arguments
when doing a
ns).
It seems that, in the O0 case, the Dwarf information is automatically
propagated to say "The input register is now here", but when I do it
in O3, I'm issuing the information in the same way.
What am I exactly missing? Any ideas why GDB would not have enough
information in this case?
Thanks,
Jean Christophe Beyler
case that there is no function call or no alloca. But I
have a case where there is a function call and it is still removed.
Any ideas ?
Thank you very much for your input,
Jc
On Wed, Nov 4, 2009 at 11:45 AM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>>> You can
solution but it seems to be that,
because I restore it in the epilogue, it considers the move as being
useless since it doesn't realize it is needed by subsequent function
calls in the function code.
Thanks for any input,
Jc
On Mon, Nov 9, 2009 at 10:40 AM, Ian Lance Taylor wrote:
> Jean Ch
Dear all,
As I continue to work on this I have found something that is surprising.
I wrote this code :
int foo (int argc, int argv)
{
bar (argv, argc);
return 0;
}
On my architecture, this is transformed into the following assembly code:
mov r6 = InputReg1
mov InputReg1 = InputReg2
mov I
Of course:
mov r6 = InputReg1
mov InputReg1 = InputReg2
mov InputReg2 = tmp
should read:
mov r6 = InputReg1
mov InputReg1 = InputReg2
mov InputReg2 = r6
Sorry about that.
Jc
On Thu, Nov 12, 2009 at 12:07 PM, Jean Christophe Beyler
wrote:
> Dear all,
>
> As I continue to work on th
why I get all these instructions. I know that
because it's signed, it is more complicated but I would prefer to get
an unsigned extract and the a shift left/shift right. Thus 3
instructions.
Right now, I get so many more instructions that represent what I
showed from the final cleanup.
Any reason for all these instructions or ideas on how to get to my 3
instructions ?
Thank you for your help and time,
Jean Christophe Beyler
rescanning insn with uid = 16.
deleting insn with uid = 16.
ending the processing of deferred insns
;; Combiner totals: 16 attempts, 16 substitutions (2 requiring new space),
;; 6 successes.
On Fri, Dec 11, 2009 at 11:57 AM, Jean Christophe Beyler
wrote:
> As I continue my work on the machine descri
Dear all,
I wanted to add an instruction via a builtin to allow users to take
advantage of some special instructions that are on my architecture.
However, the latency of the instruction is not 1 so I'll also need to
handle it in the rtx_costs function.
I had first tried to explain with the curre
On Mon, Dec 14, 2009 at 5:04 PM, Daniel Jacobowitz wrote:
> On Mon, Dec 14, 2009 at 04:46:59PM -0500, Jean Christophe Beyler wrote:
>> My current solution:
>>
>> - Define a new rtl in rtl.def
>
> Just use an unspec or unspec_volatile. You don't need a new RTL
>
instruction "z = ...;", then the compiler will
optimize out my first builtin call.
Thanks for your help and input,
Jc
On Mon, Dec 14, 2009 at 6:10 PM, Daniel Jacobowitz wrote:
> On Mon, Dec 14, 2009 at 05:52:50PM -0500, Jean Christophe Beyler wrote:
>> I thought of that but th
:08:02AM -0500, Jean Christophe Beyler wrote:
>> You are correct. So I should be changing things in the adjust_cost
>> function instead.
>>
>> I was also wondering, these instructions modify an internal register
>> that has been set as a fixed register. However, the c
Dear all,
Found on http://gmplib.org/.
"N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem
is specific to that very release; specifically gcc 4.3.1 and 4.3.3
seem to work fine."
Since porting to a newer version is difficult for me right now, I was
wondering if anybody worked on
Guenther
wrote:
> On Wed, Dec 16, 2009 at 7:50 PM, Jean Christophe Beyler
> wrote:
>> Dear all,
>>
>> Found on http://gmplib.org/.
>>
>> "N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem
>> is specific to that very release; specifi
Actually, I just finished updating my 4.3.2 to 4.3.3 and tested it and
I still have the same issue.
This seems to be a problem more than "just" 4.3.2.
Here is the test program:
#include
#include
int main() {
mpz_t a,b;
mpz_init_set_str(a, "100", 10); // program works with 10^9,
myarch64 is my port.
Then perhaps this is an back-end problem on my port. I'll try to
determine this today and keep you posted.
Jc
On Thu, Dec 17, 2009 at 9:29 PM, Jie Zhang wrote:
> On 12/18/2009 06:27 AM, Jean Christophe Beyler wrote:
>>
>> Actually, I just finished
ue, Dec 15, 2009 at 10:48 AM, Jean Christophe Beyler
wrote:
> EPILOGUE_USES does not seem to work, the code still gets optimized out.
>
> However, unspec_volatile works but then, as you have said, the
> compiler doesn't optimize out things that it then could.
>
> I hav
I am almost convinced I had tried that already but apparently not.
This seems to have fixed my problem, thank you :-)
Jc
On Thu, Jan 7, 2010 at 4:14 PM, Richard Henderson wrote:
> On 01/07/2010 12:58 PM, Jean Christophe Beyler wrote:
>>
>> Dear all,
>>
>> I've go
have to set back
the old zones (3) and (4).
Hopefully this email made some sense and some one will have an idea or
a direction I can look into,
Thanks again for all your time,
Jean Christophe Beyler
help,
Jean Christophe Beyler
On Tue, Jan 19, 2010 at 9:04 AM, Mikael Pettersson wrote:
> On Mon, 18 Jan 2010 13:55:16 -0500, Jean Christophe Beyler wrote:
>>I have a current issue on my port. Basically the stack is defined as follows :
>>
>>1) CALL_USED save area
>&g
Jean Christophe Beyler
lues and that the result was operand 0.
I added a clobber to the accumulator to say: it's been changed.
However, now if I have two myInst, the first gets optimized out...
I therefore need to define this instruction differently, any ideas ?
Thanks a lot,
Jean Christophe Beyler
Yeah that's what I had tried first but I get :
genextract: Internal error: abort in VEC_safe_set_locstr
And I can't seem to get rid of that error.
Any idea why this happens?
Jc
On Thu, Mar 4, 2010 at 6:28 PM, Andrew Pinski wrote:
> Maybe try this:
>
> (define_insn "myInst"
> [
> (set (match_
> On Thu, Mar 4, 2010 at 3:38 PM, Jean Christophe Beyler
> wrote:
>> Yeah that's what I had tried first but I get :
>>
>> genextract: Internal error: abort in VEC_safe_set_locstr
>>
>> And I can't seem to get rid of that error.
>>
>> Any id
Dear all,
I've been working on a side port for an architectural variant and
therefore there are a few differences in the assembler and linker to
be handled.
I know we can pass -Wl,option, -Wa,option from gcc down to as and ld
however if I have to write :
gcc -mArch2 -Wl,--arch2 -Wa,--arch2 hello
That's exactly what I needed, thanks a lot :-)
Worked like a charm !
Jc
On Fri, Apr 23, 2010 at 2:09 PM, Nathan Froyd wrote:
> On Fri, Apr 23, 2010 at 01:55:48PM -0400, Jean Christophe Beyler wrote:
>> I know we can pass -Wl,option, -Wa,option from gcc down to as and ld
>>
eally done in that
respect.
Thanks for your help,
Jean Christophe Beyler
,r9,0x5 #Loading the second immediate
addi r11,r9,0xf #Loading the third immediate
So my question is, can I explain this in the machine description alone
and if so, does anybody know where?
Thanks again,
Jean Christophe Beyler
On Thu, Feb 5, 2009 at 4:02 PM, Jo
n. Since
I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
5), how can I tell the compiler the different costs?
Jc
On Thu, Feb 5, 2009 at 4:10 PM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> I'm currently working on removing the constant
Ok, thanks for all this information and if you can dig that up it
would be nice too. I'll start looking at that patch and PR33699 to
see if I can adapt them to my needs. Any reason why you wouldn't
recommend it?
I will keep you posted of anything I do for latter reference,
Jean Christo
Dear all,
I have a question about the way the machine description works and how
it affects the different passes of the compiler. I was reading the GNU
Compiler Collection Internals and I found this part (in section
14.8.1):
(define_insn ""
[(set (match_operand:SI 0 "general_operand" "
Ok, I understand now. Thank you very much for your explanations,
Jean Christophe Beyler
On Sat, Feb 7, 2009 at 5:13 PM, Michael Meissner
wrote:
> On Sat, Feb 07, 2009 at 03:54:51PM -0500, Jean Christophe Beyler wrote:
>> Dear all,
>>
>> I have a question about the way th
Dear all,
I was working on the machine description so I was postponing a bit
this problem but now I have a bit more time on my hands to handle it.
I'm starting to look at the various links and code you've provided me
and will keep you posted if I make any headway or not ;-).
> For the GCC port I
es not seem to be
called anymore. Any ideas why ?
Thanks in advance,
Jean Christophe Beyler
Ahhh ok, so basically I've hit the same wall as for the constant
folding and constant propagation!
Oh well, I will see how important it is for me to try to fix it in this case.
Thanks for the answer,
Jc
On Tue, Mar 10, 2009 at 4:18 AM, Paolo Bonzini wrote:
>
>> I want the version of foo because
I set up your patch and I get an internal error on this test program:
extern void foo(int, int);
extern int bar(void);
int startup;
void foobar()
{
int i;
while(1)
{
if (bar()) {
foo(0,0);
}
}
}
Here's the error:
/home/beyler/cyclops64/src/tnt/kernel/process_manager/testn
If I replace your lines:
if ((GET_CODE (sets[i].src_elt->exp) == CONST_INT))
insert_const_anchors (dest, sets[i].src_elt, GET_MODE (dest));
with:
if ((GET_CODE (sets[i].src_elt->exp) == CONST_INT) && (INTVAL
(sets[i].src_elt->exp) != 0))
insert_const_anchors (dest, sets[i
Dear all,
I've been working on explaining to GCC the cost of loads/stores on my
target and I arrived to this problem. Consider the following code:
uint64_t sum = 0;
for(i=0; i
t len)
{
long arr[512];
...
}
Simply moves the stack pointer 512*sizeof(long) bytes down.
I suppose this is a Machine Description problem but was wondering if
you had any tips on where to look?
Thanks for your help,
Jean Christophe Beyler
Dear all,
As I work through handling load multiples and store multiples for my
target architecture, I came in front of this scenario:
int foo(int data[10240])
{
int w0, w1;
int part = 0,i ;
for (i=0; i<1;i+=2){
w0 = data[i];
w1 = data[i+1];
part += w0 + w1
Ok, I've been working at this and have actually made a bit of progress.
- I now have a framework that finds the group of loads (let's assume
they stay together).
- With the DF framework, I'm able to figure out which registers are
being used and which are free to be used.
- I've pretty much got i
Dear all,
I've been working on the Machine description of my target and was
wondering if you could help me out here.
I've been trying to force GCC out of it's habit of generating this code :
(insn 28 8 10 2 glob.c:13 (set (reg:DI 9 r9)
(mem/s:DI (symbol_ref:DI ("data") )
[4 data+0 S8 A64]
x_cost
but that's my next step.
Any comments, ideas?
Jc
On Wed, Apr 22, 2009 at 4:08 PM, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> I've been working on the Machine description of my target and was
>> wondering if you could help me out here.
>>
>
I don't see how to do to handle this case neatly, any ideas?
Thanks in advance,
Jc
On Tue, Apr 21, 2009 at 5:23 PM, Jean Christophe Beyler
wrote:
> Ok, I've been working at this and have actually made a bit of progress.
>
> - I now have a framework that finds the group of loads
Yes, I have done that and now am looking to limit those numbers. For
example, I don't copy back the ones that are not live-out registers.
It works well but I am have an issue when recompiling the whole
compiler.
I've simplified this to this, if in my reorg function, I do only this :
FOR_EACH
33 PM, Jean Christophe Beyler
wrote:
> Yes, I have done that and now am looking to limit those numbers. For
> example, I don't copy back the ones that are not live-out registers.
> It works well but I am have an issue when recompiling the whole
> compiler.
>
> I've simpli
Dear all,
I come back to you with another weirdness due to bad code generation
on my target architecture. I have a very simplified (for the moment)
rtx_costs and my address_cost is inspired by the i386 version.
However, I actually patched in the whole i386_rtx_cost function,
constraints, predicate
Ok, for the i386 port, I use uint32_t instead of uint64_t because
otherwise the assembly code generated is a bit complicated (I'm on a
32 bit machine).
The tree dump from final_cleanup are the same for the goo function:
goo (i)
{
:
return data[i + 13] + data[i];
}
However, the first RTL dump
Except if I'm mistaken, force_reg will generally call gen_reg_rtx
which does check for those two flags internally (via
can_create_pseudo_p). So you should not have that error in this case.
I suggest you use a debug_rtx on the operand that's a problem, and
first check if gen_reg_rtx is used to crea
an emit my first move and then the second but for some reason, the
compiler reassembles them back together.
Any ideas why I am getting that? Am I doing anything wrong? After I
expand this, I use the DONE macro...
Thanks,
Jc
On Fri, Jun 5, 2009 at 1:17 PM, Jean Christophe
Beyler wrote:
> It&#
into this,
Jc
On Tue, Jun 9, 2009 at 6:36 PM, Dave
Korn wrote:
> Jean Christophe Beyler wrote:
>> Dear all,
>>
>> I've moved forward on this issue. Again, the problem is not that the
>> data is not aligned but that the compiler tries to generate this
>> instructi
latest version of
GCC.
Thanks again,
Jc
On Wed, Jun 10, 2009 at 10:29 AM, Dave
Korn wrote:
> Jean Christophe Beyler wrote:
>> I'll be looking into this but I thought that GO_IF_LEGITIMATE_ADDRESS
>> is for branches ?
>
> No, absolutely not. GILA is a general filter tha
Thanks, I've pretty much finished this part of the implementation and
it seems to be working well.
Thank you all very much for your help,
Jc
On Wed, Jun 10, 2009 at 11:12 AM, Dave
Korn wrote:
> Jean Christophe Beyler wrote:
>
>> It seems that I should do the same as them n
again,
Jean Christophe
On Wed, May 13, 2009 at 4:58 PM, Jean Christophe
Beyler wrote:
> Ok, for the i386 port, I use uint32_t instead of uint64_t because
> otherwise the assembly code generated is a bit complicated (I'm on a
> 32 bit machine).
>
> The tree dump from final_c
Jean Christophe Beyler
: unrecognizable insn:
(insn 41 40 42 3 st4.c:22 (set (reg/f:DI 119)
(symbol_ref:DI ("data") )) -1 (nil))
For me this doesn't make sense since in this set, the predicate should
check the first register. The test of the if should be true, therefore
matching the second operan
turn 0;
}
bool my_move_ok(rtx op0, rtx op1)
{
if (MEM_P (op0))
return register_operand (op1, VOIDmode);
return true;
}
This seems to do what I want, now I'm going to clean up all those
constraints and see if they are compatible and work on from there.
Thanks for your help,
put that test.
On Wed, Jul 1, 2009 at 5:33 PM, Richard Henderson wrote:
> On 07/01/2009 02:02 PM, Jean Christophe Beyler wrote:
>>
>> ((reload_in_progress | reload_completed) == 0&&
>> MEM_P (op0)&& !REG_P (op1)))
>> {
>
Dear all,
I have been trying to insert function calls during a new pass in the
compiler but it does not seem to like my way of doing it. The basic
idea is to insert a function call before any load in the program
(later on I'll be selecting a few loads but for now I just want to do
it for
Browse through omp-low.c. In particular create_omp_child_function
I understand the beginning of the function with its declaration of the
function but I have a question about these lines :
/* Allocate memory for the function structure. The call to
allocate_struct_function clobbers CFUN
In create_omp_child_function, an identifier for the new function is
created. We then create a call to it using build_function_call_expr in
expand_parallel_call.
Ok so that's what I saw, is this call necessary for what I'd need :
decl = lang_hooks.decls.pushdecl (decl);
Then simplifying the
what you do seems basically OK to me. The problem is that you also need
to fix the ssa form for the virtual operands of the added calls
(i.e., you must call mark_new_vars_to_rename for each of the calls,
and update_ssa once at the end of tree_handle_loop).
Zdenek
Ok, by inserting the mark_new
Dear all,
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Interesting.
So what statements *are* in the list of data dependences if not these.
Ok apparently it's more a problem of optimization levels in O3 the
compiler
is there the data reference for it in the datarefs array?
Zdenek
Using this code after the construction of the data dependance :
datarefs = VEC_alloc (data_reference_p, heap, 10);
dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
compute_data_dependences_for_loop (lo
First of all, thanx all for all your help, I'm finally seeing the
light at the end of this long tunnel ;-)
one possibility is that the t[i-1] load got moved out of the loop by
PRE; could you check that the load is still present in the loop?
Zdenek
You're right, the load was moved to the out
98 matches
Mail list logo
