On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way these
On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote:
> On 12/14/2009 09:31 PM, John Regehr wrote:
>> Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
>> agree with both of your suggestions. I'll re-run everything w/o frame
>> pointers and ignoring testcases where some compile
HI,
Can I get an array's offset from the stack point at pass-sched?
thanks
--
Jianzhang Peng
I also wonder if you have something like LTO enabled.
No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch
the 'CC1000SendReceiveP*' definitions because they are not static
(unless he explicitly built with an export map).
Interesting.
I haven't analyzed what is going on in t
Hi!
You didn't what target you are using. Pentium D can run both 32bit
and 64bit. codes.
This was done with 32bit code. I have opened PR 42376 describing
the issue and added some more information.
Cheers,
Martin
On Mon, 2009-12-14 at 19:18 +0100, Thomas Schwinge wrote:
> Hello!
>
> I noticed the following on ARM, GCC trunk -- didn't check yet whether it
> is ARM-specific; may be a general issue.
>
> Hacking out the forcing-off of emitting CFI statements in arm.c, I see
> the following function prologue
John Regehr writes:
>> I would only be worried for cases where no warning is issued *and*
>> unitialized accesses are eliminated.
>
> Yeah, it would be excellent if GCC maintained the invariant that for
> all uses of uninitialized storage, either the compiler or else
> valgrind will issue a warni
On Tue, 2009-12-15 at 11:24 +0100, Andi Kleen wrote:
> John Regehr writes:
>
> >> I would only be worried for cases where no warning is issued *and*
> >> unitialized accesses are eliminated.
> >
> > Yeah, it would be excellent if GCC maintained the invariant that for
> > all uses of uninitialized
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
> I am not a valgrind expert so, take the following with a grain of salt
> but I think that the above statement is wrong: valgrind reliably detects
> use of uninitialized variables if you define 'use' as meaning 'affects
> control flow of your program' in valgrind.
It works in some cases for the s
On Sun, Dec 13, 2009 at 15:51, Richard Guenther wrote:
> + /* ??? We could free non-constant DECL_SIZE, DECL_SIZE_UNIT
> + and DECL_FIELD_OFFSET. But it's cheap enough to not do
> + that and refrain from adding workarounds to dwarf2out.c */
> +
> + /* DECL_FCONTEXT is only used for debug
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 compiler optimizes
them out when the accumulator is not retrieved for a calculation. How
can
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
On Tue, Dec 15, 2009 at 10: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 compiler o
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:
> 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
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 have for example an instruction to set this special register.
Theoretically, if we had :
set (x);
set
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:
> 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
On Tue, 15 Dec 2009, Diego Novillo wrote:
> On Sun, Dec 13, 2009 at 15:51, Richard Guenther wrote:
>
> > + /* ??? We could free non-constant DECL_SIZE, DECL_SIZE_UNIT
> > + and DECL_FIELD_OFFSET. But it's cheap enough to not do
> > + that and refrain from adding workarounds to dwarf2out.
Hello!
On 2009-12-15 10:15, Richard Earnshaw wrote:
> On Mon, 2009-12-14 at 19:18 +0100, Thomas Schwinge wrote:
>> .LCFI0:
>> .cfi_def_cfa_offset 8
>> + push{lr}
>> + bl __gnu_mcount_nc
>> .loc 1 4 0
>> mov r0, #33
>>
>> Sh
Also, we're not running LTO in any compiler and we removed all "static"
declarations from the code to keep compilers from making closed-world
assumptions.
John Regehr
On 12/10/09 18:33, daniel tian wrote:
Hi,
I have a problem about RTL sequence.
If I wanna generate the RTL in sequence, and don't let gcc to schedule
them.
Then you need to generate them as a single insn which outputs multiple
instructions.
Jeff
John Regehr writes:
>> I would only be worried for cases where no warning is issued *and*
>> unitialized accesses are eliminated.
>
> Yeah, it would be excellent if GCC maintained the invariant that for all
> uses of uninitialized storage, either the compiler or else valgrind will
> issue a warni
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
Snapshot gcc-4.4-20091215 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091215/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
[cross-posting to the GCC and LLVM lists]
I've updated the code size results here:
http://embed.cs.utah.edu/embarrassing/dec_09/
The changes for this run were:
- delete a number of testcases that contained use of uninitialized local
variables
- turn off frame pointer emission for all compil
John Regehr writes:
> I've updated the code size results here:
>
> http://embed.cs.utah.edu/embarrassing/dec_09/
The thing that bothers me about this is that you seem to put a lot of
emphasis on the test "X generated larger code than Y" without any
reflection of how much larger (it could be 1 b
28 matches
Mail list logo
