On Dec 6, 2010, at 6:23 PM, Dave Korn wrote:
> Tristan, sorry, you must be sick of hearing from me by now,
No, not really :-)
> but I notice the
> branch was still labile a couple of hours ago... it would be really good if we
> could get HJ's patch approved and backported before you spin the re
On 07/12/2010 08:33, Tristan Gingold wrote:
> On Dec 6, 2010, at 6:23 PM, Dave Korn wrote:
>> Tristan, sorry, you must be sick of hearing from me by now,
>
> No, not really :-)
>
>> but I notice the branch was still labile a couple of hours ago... it
>> would be really good if we could get HJ's p
Hi,
On GCC4.3 I am facing a problem due to a reload error: unable to find
register to spill in class 'CHIP_REGS'.
This happens on a really nasty set of rules that involve expands, splits
and a TARGET_SECONDARY_RELOAD. Since this code has been brough through
some older GCC versions, I am trying to
On 12/06/10 15:07, Ian Lance Taylor wrote:
roy rosen writes:
If I have two load SI insns. Is there any way to combine them into one
load DI insn?
Not using peephole which can catch only this limited case of being
sequential insns.
I have seen something done in ARM (*arith_adjacentmem) but it i
pocma...@gmail.com (Paulo J. Matos) writes:
> This happens on a really nasty set of rules that involve expands, splits
> and a TARGET_SECONDARY_RELOAD. Since this code has been brough through
> some older GCC versions, I am trying to get around to refactor it and
> hopefully in the end, get rid of
Ian Lance Taylor writes:
> [snip]
> after register allocation. After the second split, no output template
> should still be "#".
>
What do you mean by your last sentence? It somehow makes me think that
the splits work at some preprocessing level replacing/rewriting the output
template of instru
Hi all,
I play a bit with lto optimisation. As I see, some functions will be inlined
during link stage which is the expected result. But the function code which is
always inlined is not removed from the output file which will result in larger
output files.
Any additional option to use with gcc
On Dec 7, 2010, at 9:51 AM, Paulo J. Matos wrote:
> Ian Lance Taylor writes:
>
>> [snip]
>> after register allocation. After the second split, no output template
>> should still be "#".
>>
>
> What do you mean by your last sentence? It somehow makes me think that
> the splits work at some pr
On Tue, Dec 7, 2010 at 4:02 PM, Klaus Rudolph wrote:
> Hi all,
>
> I play a bit with lto optimisation. As I see, some functions will be inlined
> during link stage which is the expected result. But the function code which
> is always inlined is not removed from the output file which will result
Paul Koning writes:
>> I assume you by 'instruction' here mean a define_insn and not a single
>> RTL or assembler instruction.
>>
>> So, assume I have two classes M_REGS and Y_REGS and I cannot move
>> between them except if I go through an intermediary in C_REGS.
>> Do I need a secondary rel
On Dec 7, 2010, at 10:30 AM, Paulo J. Matos wrote:
> Paul Koning writes:
>
>>> I assume you by 'instruction' here mean a define_insn and not a single
>>> RTL or assembler instruction.
>>>
>>> So, assume I have two classes M_REGS and Y_REGS and I cannot move
>>> between them except if I go th
Paul Koning writes:
>
> I don't know enough to answer that. But I do know that the secondary
> reload stuff works great, and is reasonably well documented, and it
> takes only a few lines to put into effect. Why not give it a try?
Thanks for your input Paul.
Actually the problem is exactly tha
On 12/07/10 08:30, Paulo J. Matos wrote:
Paul Koning writes:
I assume you by 'instruction' here mean a define_insn and not a single
RTL or assembler instruction.
So, assume I have two classes M_REGS and Y_REGS and I cannot move
between them except if I go through an intermediary in C_REGS.
Do
pocma...@gmail.com (Paulo J. Matos) writes:
> Paul Koning writes:
>
>>> I assume you by 'instruction' here mean a define_insn and not a single
>>> RTL or assembler instruction.
>>>
>>> So, assume I have two classes M_REGS and Y_REGS and I cannot move
>>> between them except if I go through an
Jeff Law writes:
> You're better off taking the time to understand how secondary reloads
> work. In addition to your port working better, the knowledge you gain
> will help you with other maintenance burdens with your port.
Yes, I think you're right. It seems to be a powerful tool that I have
b
Actually after your explanation below, a lot of things make total
sense. Thanks, that cleared out several things to me.
However, there's a specific secondary reload question still bothering me:
- I have seen cases where secondary reload is called and sri->icode !=
CODE_FOR_nothing. In which case
On 12/07/10 09:30, Paulo J. Matos wrote:
Jeff Law writes:
You're better off taking the time to understand how secondary reloads
work. In addition to your port working better, the knowledge you gain
will help you with other maintenance burdens with your port.
Yes, I think you're right. It see
pocma...@gmail.com (Paulo J. Matos) writes:
> However, there's a specific secondary reload question still bothering me:
> - I have seen cases where secondary reload is called and sri->icode !=
> CODE_FOR_nothing. In which cases does this happen and should I touch it if
> the reload required no se
Hi GNU,
I'm trying to write my own game engine and, I've got it to work for my
Wii, and for my Xbox360, but to get it to work on PlayStation is
difficult.
A buddy of mine told me about the gcc compiler and that people have used
to build games for the PS3 systems. He even said that PlayStation has
"Gene Michaelson" writes:
> I'm trying to write my own game engine and, I've got it to work for my
> Wii, and for my Xbox360, but to get it to work on PlayStation is
> difficult.
>
> A buddy of mine told me about the gcc compiler and that people have used
> to build games for the PS3 systems. He
Ian Lance Taylor writes:
>
> The TARGET_SECONDARY_RELOAD hook should set sri->icode to some value if
> there is a specific insn pattern which will do the actual secondary
> reload.
>
> A good example for complex secondary reloads is sh_secondary_reload in
> config/sh/sh.c.
>
Thanks Ian!
--
PMa
Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
> On 12/06/10 15:07, Ian Lance Taylor wrote:
> Given the two loads don't have a def-use data dependency combine won't
> ever get the opportunity to do anything with them. In general there is
> no pass which combines insns without a true
Hi,
Are any kinds of flow-dependent points-to analysis computed on gimple
in ssa form?
in which pass?
regards,
Eugen
On Mon, Dec 6, 2010 at 9:20 AM, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>> On 06/12/2010 02:20, H.J. Lu wrote:
>>
>>> BTW, the new linker passed bootstrap-lto with all default languages.
>>> I am planning to include this patch in the next Linux binutils.
>>>
On Mon, Dec 6, 2010 at 4:05 PM, H.J. Lu wrote:
>>
>> Without slim lto you never know if a duplicate symbol is a mistake
>> of the programmer or just the "fat lto" copy. Also ELF semantics
>> like weak are hard if you have multiple copies.
>>
>
> It isn't easy, but doable.
>
Here is my proposal.
Snapshot gcc-4.4-20101207 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101207/
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
On 12/07/10 12:29, Frédéric RISS wrote:
Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
On 12/06/10 15:07, Ian Lance Taylor wrote:
Given the two loads don't have a def-use data dependency combine won't
ever get the opportunity to do anything with them. In general there is
no pass wh
> Here is my proposal. Any comments?
We talked about ld -r a while back during the WHOPR project, and the
two ways that the linker could work: (1) combine all the .o files and
use the plugin to run LTRANS on the IR files, producing a pure,
optimized, object file; and (2) combine the non-IR object
On 07/12/2010 23:15, Cary Coutant wrote:
>> ○ Object-only section:
>> § Section name won't be generated by any tools, something like
>> ".objectonly\004".
>> § Contains non-IR object file.
>> § Input is discarded after link.
>
> Please -- use a spec
On Tue, Dec 7, 2010 at 3:15 PM, Cary Coutant wrote:
>> Here is my proposal. Any comments?
>
> We talked about ld -r a while back during the WHOPR project, and the
> two ways that the linker could work: (1) combine all the .o files and
> use the plugin to run LTRANS on the IR files, producing a pu
On Tue, Dec 7, 2010 at 3:53 PM, H.J. Lu wrote:
> On Tue, Dec 7, 2010 at 3:15 PM, Cary Coutant wrote:
>>> Here is my proposal. Any comments?
>>
>> We talked about ld -r a while back during the WHOPR project, and the
>> two ways that the linker could work: (1) combine all the .o files and
>> use t
On Tue, Dec 7, 2010 at 3:57 PM, Andrew Pinski wrote:
> On Tue, Dec 7, 2010 at 3:53 PM, H.J. Lu wrote:
>> On Tue, Dec 7, 2010 at 3:15 PM, Cary Coutant wrote:
Here is my proposal. Any comments?
>>>
>>> We talked about ld -r a while back during the WHOPR project, and the
>>> two ways that the
On Tue, Dec 7, 2010 at 3:58 PM, H.J. Lu wrote:
> On Tue, Dec 7, 2010 at 3:57 PM, Andrew Pinski wrote:
>> On Tue, Dec 7, 2010 at 3:53 PM, H.J. Lu wrote:
>>> On Tue, Dec 7, 2010 at 3:15 PM, Cary Coutant wrote:
> Here is my proposal. Any comments?
We talked about ld -r a while back
>> Here is my proposal. Â Any comments?
>
> We talked about ld -r a while back during the WHOPR project, and the
> two ways that the linker could work: (1) combine all the .o files and
> use the plugin to run LTRANS on the IR files, producing a pure,
> optimized, object file; and (2) combine the no
On 12/07/2010 04:20 PM, Andi Kleen wrote:
>
> The only problem left is mixing of lto and non lto objects. this right
> now is not handled. IMHO still the best way to handle it is to use
> slim lto and then simply separate link the "left overs" after deleting
> the LTO objects. This can be actually
On Tue, Dec 7, 2010 at 4:20 PM, Andi Kleen wrote:
>>> Here is my proposal. Any comments?
>>
>> We talked about ld -r a while back during the WHOPR project, and the
>> two ways that the linker could work: (1) combine all the .o files and
>> use the plugin to run LTRANS on the IR files, producing a
On Tue, Dec 7, 2010 at 4:24 PM, H. Peter Anvin wrote:
> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>
>> The only problem left is mixing of lto and non lto objects. this right
>> now is not handled. IMHO still the best way to handle it is to use
>> slim lto and then simply separate link the "left o
On 12/07/2010 03:58 PM, Dave Korn wrote:
> On 07/12/2010 23:15, Cary Coutant wrote:
>
>>> ○ Object-only section:
>>> § Section name won't be generated by any tools, something like
>>> ".objectonly\004".
>>> § Contains non-IR object file.
>>> § Input
"H. Peter Anvin" writes:
> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>
>> The only problem left is mixing of lto and non lto objects. this right
>> now is not handled. IMHO still the best way to handle it is to use
>> slim lto and then simply separate link the "left overs" after deleting
>> the
On Tue, Dec 7, 2010 at 5:39 PM, Ian Lance Taylor wrote:
> "H. Peter Anvin" writes:
>
>> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>>
>>> The only problem left is mixing of lto and non lto objects. this right
>>> now is not handled. IMHO still the best way to handle it is to use
>>> slim lto and
On Tue, Dec 7, 2010 at 12:12 PM, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 9:20 AM, H.J. Lu wrote:
>> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>>> On 06/12/2010 02:20, H.J. Lu wrote:
>>>
BTW, the new linker passed bootstrap-lto with all default languages.
I am planning to
41 matches
Mail list logo
