On 08/07/11 15:58, Paulo J. Matos wrote:
However, you hinted to using combine. I am wondering if I can combine
and into a memory-memory move in HImode and straight away split into the
4 insn above. In the end 4.6.1 would end up doing the same at combine
time as 4.5.3 in expand time. I have to
On 12/07/11 08:22, Paolo Bonzini wrote:
On 07/11/2011 07:56 PM, David Malcolm wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
On 12/07/11 17:04, Paolo Bonzini wrote:
It shows bugs in GCC's pass description, to be clear.
Paolo
That makes sense.
--
PMatos
Hi all,
As part of a testsuite script I am parsing GCC's output and I noticed
that format specifier %qs quotes the string by surrounding it with
unicode characters. I can't find where this %qs is defined so that I can
try and override it to quote with '%s' or `%s'. Anything but unicode.
Any
Hello,
I am trying to size-optimise one of our instructions. That's addhi3.
HImode is 32 bits and QImode is 16bits, which is what our processor
instructions work with.
So generally an addhi3 looks like:
(define_insn "addhi3"
[(set (match_operand:HI 0 "nonimmediate_operand" "=c")
(
On 18/07/11 19:00, Richard Henderson wrote:
"Specifically represent... the carry flag" means using the CCmode
style of condition code handling, right?
Yes.
hummm, we are still using the old mode for condition code handling. From
what you're saying we need to use the new CCmode. I was loo
On 18/07/11 17:53, Richard Henderson wrote:
Therefore in order to expose the carry flag
before reload, you must have an add instruction that does not modify the
carry. Some processors have this in the form of a "load-effective-address"
instruction.
An add instruction that doesn't modify carry.
On 18/07/11 17:58, Ian Lance Taylor wrote:
Look at add3_cc in gcc/config/i386/i386.md. Look at how
add3_doubleword splits to use it.
Thanks Ian, from what Richard said I need an add that doesn't modify
carry in order to follow the approach there. Since I don't I guess I
have to look for ho
On 19/07/11 09:21, Paulo J. Matos wrote:
hummm, we are still using the old mode for condition code handling. From
what you're saying we need to use the new CCmode. I was looking at the
internal documents and even though it doesn't seem required to have a
hard register to keep the condi
On 18/07/11 17:53, Richard Henderson wrote:
Otherwise, have a look at the mn10300 and rx ports.
Looking at rx.c, flag_from_code:
static unsigned int
flags_from_code (enum rtx_code code)
{
switch (code)
{
case LT:
case GE:
return CC_FLAG_S;
...
For GE, shouldn't you also n
On 19/07/11 11:20, Paulo J. Matos wrote:
For GE, shouldn't you also need CC_FLAG_Z ?
I just got it! :) No need for CC_FLAG_Z!
--
PMatos
On 18/07/11 17:53, Richard Henderson wrote:
Otherwise, have a look at the mn10300 and rx ports.
What's the idea behind the rx port *_flags alternative define_insn?
For example:
(define_insn "abssi2"
[(set (match_operand:SI 0 "register_operand" "=r,r")
(abs:SI (match_operand:S
On 19/07/11 16:06, DJ Delorie wrote:
What's the point of the second define insn? The first insn seems to
take us from expansion to asm generation so I can't see where the
second one will come into play except in an expansion after reload
but that doesn't happen, right?
IIRC it has to do with op
On 19/07/11 16:36, Richard Henderson wrote:
But I am still confused as to how GCC matches them. Is *_flags any
special name GCC loops for (doubtful)?
No, and as you can see from the leading "*" in the name, the
name is not actually visible as a pattern.
Thought so... :)
As an experiment, p
On 19/07/11 16:41, Richard Henderson wrote:
Note that while RX has one mode for floating-point, it has
two other modes to deal with instructions that fail to set
all of the flags (or fails to set the flags in a way that
is useful for the comparison).
Depending on how regular your instructions ar
On 19/07/11 16:41, Richard Henderson wrote:
(or fails to set the flags in a way that
is useful for the comparison).
I am not sure I understand the above. Could you give an example where
certain flags might be set but are not useful for comparison?
--
PMatos
Hi,
After the discussion we had on the previous thread 'splitting add
instructions', I added support for TARGET_FLAGS_RENUM to my port along
with *_flags rules similar to how it is done in rx backend (gcc 4.6.1).
Then I decided to create a very simple C program:
unsigned long foo(unsigned int
On 22/07/11 00:47, Diogo Sousa wrote:
But readers will focus on the word "Issue" here and think that there is
something missing. Perhaps there should be a footnote explaining that
glibc/eglibc has the needed support, but that other libraries might not.
I agree. It should say something as "Li
On 22/07/11 16:22, Joern Rennecke wrote:
I have to disagree, library issue means that it's an issue with the
library, not gcc.
It still makes sense to clarify the language to indicate that, depending on
the library used, this might be, in fact, a library non-issue.
We might be interpreting t
I wanted to let everyone know that the planning for the 2011 GCC and GNU
Toolchain Developers' Summit is well underway and I hope to have the
dates and locations confirmed any time now. The aim is the same timing
as 2010 in the 3rd week of October.
Start thinking about the topics you're most
Hi,
I am having a size optimisation issue with GCC-4.6.1.
The problem boils down to the fact that I have no idea on the best way
to hint to GCC that a given insn would make more sense someplace else.
The C code is simple:
int16_t mask(uint32_t a)
{
return (x & a) == a;
}
int16_t is QImode
On 10/08/11 12:40, Richard Guenther wrote:
On x86 we expand the code to ((xl& al) ^ al) | ((xh& ah) ^ ah) == 0
which is then if-converted. Modified testcase:
long long x;
_Bool __attribute__((regparm(2))) mask (long long a)
{
return (x& a) == a;
}
on i?86 gets you
mask:
.LFB0:
On 10/08/11 12:42, Richard Guenther wrote:
Oh, and I wonder if/why IRA can/does not rematerialize the constant
instead of spilling it. Might be a cost issue that it doesn't delay
allocating a reg for 1 as that is cheap to reload (is it?).
I would indeed expect IRA to move the constant assign
On 10/08/11 14:51, Richard Guenther wrote:
I think it's all happening in generic code via do_store_flag.
ah, now I understand your previous question. I wonder if it's not
triggered because I don't have cstore4 defined. Might be that but
I have to look deeper.
--
PMatos
On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
> I can not reproduce the problem. It would be nice to give all info (the
> code without includes and all options). In this case I could have more info
> to say more definitely about the reason of the problem in IRA.
>
One of the issue wi
On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
> I can not reproduce the problem. It would be nice to give all info (the
> code without includes and all options). In this case I could have more info
> to say more definitely about the reason of the problem in IRA.
>
Let me add another
On Thu, Aug 11, 2011 at 3:27 PM, Vladimir Makarov wrote:
> Yes, that is mostly correct. The first could be done by -fweb (if the live
> range where the pseudo is equal to the constant is disjoint). The first
> could be done also by Jeff Law's project which can provide splitting not
> only on th
On Fri, Aug 12, 2011 at 3:21 PM, Vladimir Makarov wrote:
>
> Sorry, Paulo. I don't think it is a good idea to have such a general pass.
Thanks for the observation and the points you made. I understand and
agree that this should be sorted at the IRA level. What I might do in
the meantime is to im
Hi,
I am trying to fix 49801 from GCC 4.6.1.
One of the first things I noticed it that one of the BB at asmconst
looks like:
;; Start of basic block ( 2) -> 3
;; bb 3 artificial_defs: { }
;; bb 3 artificial_uses: { u7(4){ }u8(5){ }u9(6){ }}
;; lr in4 [AP] 5 [Y] 6 [Y] 26 27
;; lr use
Hi,
genmodes.c has the following comment:
/* Again, nothing more need be said. For historical reasons,
the size of a CC mode is four units. */
validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
m->bytesize = 4;
Now, this is probably ok for _most_ a
Hi,
I am noticing a very concerning change of behaviour from GCC45 to GCC46
on our applications.
The following code:
static const unsigned int foo = 1;
unsigned int test( void )
{
const volatile unsigned int *bar = &foo;
return ( *bar );
}
in GCC45 works as expected:
$test:
ld AL,#foo
On 20/09/11 17:35, Ian Lance Taylor wrote:
I agree that this looks like a bug. Please file a bug report marked as
a regression.
Ian
Thanks. Reported as 50472 even though I am just reading Davids post and
he is convincing me that this might not be a bug after all, however, it
is still behav
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant.
But since I am accessing the data through the pointer and the pointer
qualifies the data as volatile, shouldn't the c
On 21/09/11 15:21, David Brown wrote:
And since this
situation would not occur in real code (at least, not code that is
expected to do something useful other than test the compiler's code
generation), there is no harm in making sub-optimal object code.
Actually the reason why I noticed this is
Hi,
After the discussion about the use of CCmode in:
http://gcc.gnu.org/ml/gcc/2011-07/msg00303.html
I am trying to ditch support for the only cc0 attr and add support for
CC_REG.
There are two issues that are making the situation more complicated,
both of similar nature.
My addition instr
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of this issue.
--
PMatos
On 23/09/11 12:33, Paulo J. Matos wrote:
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make
sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of
On 23/09/11 08:21, Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
Ok. Actually I
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
My hopes were high but unfortunately it is not fixed yet.
git head 36181f98 still generates the same unexpected code.
Cheers
On Fri, 23 Sep 2011 09:30:48 -0400, amylaar wrote:
> Hiding the flags register would mean it is not represented in the rtl at
> all. You can have combined compare-branch instructions. Of course,
> going that route would mean that the model you present to GCC is even
> further from the hardware th
Hi,
I was tracking down an assertion failure in GCC which occured while I
was trying to bend some GCC constraints.
I came accross this function `insn_invalid_p', which calls
`added_clobbers_hard_reg_p' and before calling it, has the comment:
/* If we have to add CLOBBERs, fail if we have to
On 26/09/11 17:23, Ian Lance Taylor wrote:
The function added_clobbers_hard_reg_p is a generated function. So
another approach would be some sort of attribute which directs the
generator (genemit) to ignore certain hard registers.
This definitely sounds like the best approach for my specific
"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
"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
Hi,
I am trying to find where IRA, is deleting trivial insn like:
(set r1 r1)
The problem I am facing is that I have managed to convince GCC to handle
moves that clobber RCC like:
(parallel [(set reg1 reg2) (clobber rcc)])
However, I am getting loads of insn like:
(parallel [(set r1 r2) (clobb
Ian Lance Taylor writes:
> pa...@matos-sorge.com (Paulo J. Matos) writes:
>
>> I am trying to find where IRA, is deleting trivial insn like:
>> (set r1 r1)
>
> Search for "Discard obvious no-ops" in the function reload in the file
> gcc/reload1.c.
Thanks, that's exactly it.
--
PMatos
Suddenly bugzilla went down.
Am I the only one seeing this?
--
PMatos
On 06/10/11 15:41, Paulo J. Matos wrote:
Suddenly bugzilla went down.
Am I the only one seeing this?
Opps, now sorted.
--
PMatos
Hi,
To negate a double word (HImode) register, I used to take the
instruction all the way to assembly generation and then expand into
three assembly instructions like so:
xor %t0, # ; invert bits in top word of op0
nadd %b0, #0; negate bottom bits of op0
addc %t0, #0; add ca
On 17/10/11 17:20, Andrew Pinski wrote:
On Mon, Oct 17, 2011 at 3:50 AM, Paulo J. Matos wrote:
addc_internal looks like:
(define_insn "addc_internal"
[(set (match_operand:QI 0 "nonimmediate_operand" "=c")
(plus:QI
(plus:QI
(lt
On 18/10/11 06:12, vikramsp wrote:
In my .md file there is an insn
(define_insn abssf2
(clobber (match_scratch 2 ""))
the %2 register is allocated as r0 in the real code.
My problem is that i want other than r0 to be allocated
for operand 2.
Please help how to do t
On 19/10/11 00:10, Richard Henderson wrote:
The thing that's almost certainly missing is that the NAND pattern
must SET your flags register, not simply clobber it. Otherwise the
dependency between the ADDC and the NAND will never be created properly.
I understand that there's a missing SET o
Hi,
And by rules of the game, I mean the semantics of the insn chain.
In comes in the sequence of a previous post where I am splitting a neghi
operation like this:
op0 = negHI(op1)
expands to:
op0 = op1
op0_HIGH = xorQI(op0_HIGH, -1)
parallel(
op0_LOW = negQI(op0_LOW)
op0_HIGH = add(op
On 20/10/11 15:06, Anitha Boyapati wrote:
Firstly, aren't discriminators introduced in DWARF 4? Little more
digging shows that the following fix is missing in 4.6.1 release. It
breaks the current dwarf2 parsers/readers. I think it is worth filing
a bug.
Anitha, if you only want dwarf2 produce
On 20/10/11 16:25, Ulrich Weigand wrote:
When reload looks at the above pattern, it will see just
two operands, both of which are output-only. So when it
decides to reload one of the operands, it will only provide
an output reload, no input reload.
For operands that are actually used for both
On 20/10/11 18:12, Joern Rennecke wrote:
Or just change the constraint to "+c" .
After trying Ulrichs suggestion and getting it to work I decided to give
yours a try since it looked cleaner using +c and dups elsewhere.
However, it failed to compile libgcc with:
../../../../../../../devHost
On 21/10/11 10:02, Paolo Bonzini wrote:
On 10/20/2011 07:46 PM, Paulo J. Matos wrote:
However, it failed to compile libgcc with:
../../../../../../../devHost/gcc46/gcc/libgcc/../gcc/libgcc2.c:272:1:
internal compiler error: in df_uses_record, at df-scan.c:3178
This feels like a GCC bug. I
On 19/10/11 01:48, paul_kon...@dell.com wrote:
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Richard
Henderson
On 10/17/2011 03:50 AM, Paulo J. Matos wrote:
...
(for example, it would be ok to output negqi2, xorqi3 and
addc_internal since xorqi3 only sets N and Z, not
On 21/10/11 22:41, Richard Henderson wrote:
On 10/21/2011 10:15 AM, Paulo J. Matos wrote:
So I have implemented the nadd and addc as:
(define_insn "negqi2"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_operand:QI 1 "register
On 23/10/11 22:21, Richard Henderson wrote:
On 10/21/2011 05:49 PM, paul_kon...@dell.com wrote:
There are lots of parts of the compiler that don't optimize well when an insn
has more than one output. For the normal insn, just clobber the flags; don't
include a second SET.
Yes, but... isn't
On 28/10/11 17:59, Richard Henderson wrote:
On 10/28/2011 06:49 AM, Peter Bigot wrote:
I'm inclined to follow sparc's lead, but is one or another of the choices
more likely to help combine/reload/etc do a better job?
I don't know.
In the case of RX, we don't model CC_REG until after reload, s
On 29/10/11 18:33, Peter Bigot wrote:
On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson wrote:
On 10/29/2011 05:41 AM, Peter Bigot wrote:
It seems cc0 should probably still be preferred for CISC-style
architectures like the MSP430. I'll give that approach a try.
I think that's somewhat un
On 31/10/11 05:36, Hans-Peter Nilsson wrote:
BTW, I
don't think it helps that someone decided the canonical form of
a parallel that includes a CC-setter must have the CC-setting
*first* (contrasting with the position of clobbers)...
How did you reach this conclusion?
--
PMatos
On 01/11/11 02:43, Hans-Peter Nilsson wrote:
Not obvious or maybe I was unclear as to what I alluded?
In the below insn-bodies, "sub" is the insn that sets cc0 as a
side-effect.
Supposed canonical form :
(parallel
[(set cc_reg) (compare ...))
(set destreg) (sub ...))])
and:
(parallel
[(
, and if needs be, I have several x32 and x64 macs I can test things on.
--
Alex J Avriette
http://search.cpan.org/~alex/
http://www.linkedin.com/in/avriette (+1 858 3677293)
Hi,
I am finding slightly confusing the difference between
outgoing_args_size and pretend_args_size.
I think I understand pretend_args_size, at least on the specific case of
my port. The first two words of arguments go into two register the
remaining goes into the stack. However, if the firs
On 13/12/11 14:47, Ian Lance Taylor wrote:
outgoing_args_size is the number of bytes required by called functions.
In your question above, the answer is no; x is an incoming argument. If
you write
extern foo(int);
void bar(void) { foo (1); }
then the outgoing_args_size of bar is sizeof(int), b
Hi,
I have the very simple:
volatile unsigned int SOME_REGISTER;
volatile unsigned long ANOTHER_REGISTER;
void foo_bar(void)
{
SOME_REGISTER = 0;
ANOTHER_REGISTER = 0;
}
causing me some headaches: int is QImode, long is HImode.
Using gcc-4.6.2, in 175r.fwprop2 I have:
(insn 6 2 7 2 (parall
Hi,
I am developing a new pass and looking for suggestions on the best way
to record in a data structure which regs and subregs I have seen and
which mode they are in through the insn chain so I know if I find
duplicates.
Any suggestions on the best way to do this?
Are there any rtx hashes a
A member of our team was working on some switch statement optimizations,
and ran into a situation that seems a little curious on the face of it.
Consider these two test variants:
int
test_switch_1 (unsigned int *index, int i)
Great, thanks! Results are good on this specific test case. Seems like
a nice thing to add in 4.8.
On Fri, 2012-01-27 at 18:40 +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 27 Jan 2012, William J. Schm
Hi,
In order to pursue an optimization I am explicitly defining a cbranchhi4
and manually expanding to calls to cbranchqi4 or similar.
Do I need to attach probabilities notes to jumps emitted during the
expand phase?
Cheers,
--
PMatos
Hi,
The docs state:
`cbranchmode4'
Conditional branch instruction combined with a compare instruction.
Operand 0 is a comparison operator. Operand 1 and operand 2 are the first
and second operands of the comparison, respectively. Operand 3 is a
label_ref that refers to the label to jump to
ld like me to provide?
Thank you,
Charles J. Tabony
Adam Nemet wrote:
> "Charles J. Tabony" writes:
> > I see the same difference between GCC 4.3.2 and 4.4.0 when compiling
> > for PowerPC, MIPS, ARM, and FR-V.
>
> I can confirm this with mainline on MIPS/Octeon. Can you please file a
> bug.
File
ge and any control-flow post-dominated by that edge?
Thank you,
Charles J. Tabony
Hello,
I have been trying to implement sibcalls (you can see my digression
yesterday in gcc-help) for an arch with gcc 4.3.4.
The problem with this is that I only want to sibcall when it happens
to reduce my code size.
I noticed (in the internals manual) we cannot actually fallback to a
normal ca
Hi all,
With the code:
-
extern void display(unsigned int);
void callee(int z) // Sibcall worth it
{
display(z);
}
void caller(int x, int y) // Sibcall not worth it
{
display(x);
display(y);
callee(x*y);
}
-
I have put a f
On Thu, Jan 7, 2010 at 11:46 AM, Paulo J. Matos wrote:
> Hi all,
>
> With the code:
> -
> extern void display(unsigned int);
>
> void callee(int z) // Sibcall worth it
> {
> display(z);
> }
>
> void caller(int x, int y) // Sib
On Thu, Jan 7, 2010 at 5:29 PM, Dave Korn
wrote:
> Paulo J. Matos wrote:
>
>> The problem with this is that I only want to sibcall when it happens
>> to reduce my code size.
>>
>> I noticed (in the internals manual) we cannot actually fallback to a
>> normal ca
Hi all,
I just noticed that the pro_and_epilogue pass in gcc3.4.3 for certain
functions is ran multiple times with sibcalls enabled. Why is that?
What I did was to put a printf on the epilogue and sibcall_epilogue
pattern so that during compilation it prints the name of the function
currently gen
On Fri, Jan 8, 2010 at 3:34 PM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> I just noticed that the pro_and_epilogue pass in gcc3.4.3 for certain
>> functions is ran multiple times with sibcalls enabled. Why is that?
>>
>> What I did
Hi all,
I am using gcc 4.3.4 to loop through the gimple tree to find
CALL_EXPR. This is what I have (even though I tried several variants,
none of which worked):
tree body_stmt = DECL_SAVED_TREE (current_function_decl);
while (body_stmt) //
{
if (TREE_CODE (body_stmt) == CALL_EXPR)
On Mon, 2010-01-11 at 17:51 +0100, Richard Guenther wrote:
> On Mon, Jan 11, 2010 at 4:46 PM, Paulo J. Matos wrote:
> > Hi all,
> >
> > I am using gcc 4.3.4 to loop through the gimple tree to find
> > CALL_EXPR. This is what I have (even though I tried several variant
On Tue, Jan 12, 2010 at 10:43 AM, Richard Guenther
wrote:
>
> Because it talks about trees as used by the C / C++ frontends
> and it is way out of date anyway.
>
Thanks, the tree iterator did the trick.
I was wondering if there is a tree-walker which walks through the
whole tree, going through al
On Tue, Jan 12, 2010 at 11:30 AM, Richard Guenther
wrote:
>
> There is walk_tree.
>
Thanks! Guess I should have guessed that! :)
> Richard.
>
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
Hi all,
I have the following function:
unsigned int fact_aux(unsigned int n, unsigned int k)
{
if(n == 0)
return k;
else
return fact_aux(n - 1, k * n);
}
unsigned int facti(unsigned int n)
{
return fact_aux(n, 1);
}
Gcc4.3.4 when I compile functions with : -Os -fno-i
Hi,
I am trying to walk through the body of the current_function_decl in
TARGET_FUNCTION_OK_FOR_SIBCALL for a specific arch in gcc 4.3.4. I am
using DECL_SAVED_TREE but it's not working as I expect.
For the c file:
extern unsigned int source_size(void *s);
extern void source_drop_no_checks(void *s
On Fri, Jan 15, 2010 at 8:56 AM, Paulo De Oliveira Cantante De Matos
wrote:
>
>
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>> Behalf Of Andrew Pinski
>> Sent: 14 January 2010 17:08
>> To: Paulo J. Matos
&
anybody has a faint idea on how this works, please let me know.
Thanks,
Paulo Matos
On Thu, Jan 14, 2010 at 5:00 PM, Paulo J. Matos wrote:
> Hi,
>
> I am trying to walk through the body of the current_function_decl in
> TARGET_FUNCTION_OK_FOR_SIBCALL for a specific arch in gcc 4.3.4.
Hi,
As a continuation of my previous issue, what's the difference between
cfun and current_function_decl and which one should I use to walk the
tree during TARGET_FUNCTION_OK_FOR_SIBCALL?
[In the internals document I only found references to cfun and even
there was hard to understand what it actu
On Mon, Jan 18, 2010 at 10:30 AM, Richard Guenther
wrote:
> On Mon, Jan 18, 2010 at 11:24 AM, Paulo J. Matos wrote:
>> Hi,
>>
>> As a continuation of my previous issue, what's the difference between
>> cfun and current_function_decl and which one should
On Mon, Jan 18, 2010 at 12:58 PM, Richard Guenther
wrote:
>
> Yes. During expansion we destroy the trees.
>
Is there a way to avoid tree destruction? Maybe through a flag?
If not, what I need is in the hook, to know if the caller, calls any
other functions besides the one we are evaluating the s
On Mon, Jan 18, 2010 at 1:25 PM, Richard Guenther
wrote:
>
> Look at cgraph_node (cfun->decl)->callers
>
> Richard.
>
Exactly what I need. :) And the day looks brighter now!
Thank you very much.
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
Hi,
I have declared a builtin that receives a function pointer in gcc 4.3.4.
While handling the builtin I want to find the assembler name of the
function the pointer points to.
My current code works if the the function is a void (*)(void), but it
doesn't work for anything else and unfortunately,
This question is in response to Ian's answer here:
Ref: http://gcc.gnu.org/ml/gcc/2009-07/msg00462.html
Adding to the referenced inquiry, there are on the machine a condition
codes register for each register.
I would like to model this by writing define_insns in such a way as to
access a regis
On Wed, Jan 27, 2010 at 12:25 PM, Paulo J. Matos wrote:
> Now, I wonder in this more general case, where can I obtain the
> function decl (so I can get its assembler name) for the function the
> pointer is pointing to?
>
Allow me to revive this question by asking if I can obtain
Hi all,
After reading the internal docs about rtx_costs I am left wondering what
they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estimating how many assembler in
Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the as
Hi,
>From http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html
I get that 4.3.5 should come out after 4.4.2, however, 4.4.2 has come
and gone (with 4.4.3) and no 4.3.5.
Any ideas when this is going to be released?
Thanks,
--
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net
401 - 500 of 820 matches
Mail list logo
