On 10/29/19 3:24 PM, Jan Hubicka wrote:
>> gcc/cgraph.c | 14 ++
>> gcc/cgraphclones.c | 5 +
>> gcc/ipa-fnsummary.c | 2 +-
>> gcc/ipa-hsa.c| 2 +-
>> gcc/ipa-icf.c| 2 +-
> gcc/cgraph.c | 14 ++
> gcc/cgraphclones.c | 5 +
> gcc/ipa-fnsummary.c | 2 +-
> gcc/ipa-hsa.c| 2 +-
> gcc/ipa-icf.c| 2 +-
> gcc/ipa-prop.c | 6
On 10/22/19 1:09 PM, Martin Liška wrote:
> @Honza: PING^1
>
> On 9/18/19 12:14 PM, Martin Liška wrote:
>> On 9/11/19 1:38 PM, Martin Liška wrote:
>>> The inline_clone manipulation happens in cgraph_node::find_replacement where
>>> we manipulate the clone_of.
>>
>> I fixed that but there's a simila
@Honza: PING^1
On 9/18/19 12:14 PM, Martin Liška wrote:
> On 9/11/19 1:38 PM, Martin Liška wrote:
>> The inline_clone manipulation happens in cgraph_node::find_replacement where
>> we manipulate the clone_of.
>
> I fixed that but there's a similar situation which goes other way around:
>
> cgrap
On 9/11/19 1:38 PM, Martin Liška wrote:
> The inline_clone manipulation happens in cgraph_node::find_replacement where
> we manipulate the clone_of.
I fixed that but there's a similar situation which goes other way around:
cgraph_node *
cgraph_node::get_create (tree decl)
{
cgraph_node *first_c
On 9/9/19 4:33 PM, Jan Hubicka wrote:
>> PING^1
>>
>> On 8/26/19 12:04 PM, Martin Liška wrote:
>>> Ok. I have a semi-working patch that has issues for inline clones.
>>> When we call cgraph_node::get_untransformed_body for an inline clone,
>>> then one needs to use clone_of->order to find proper LT
> PING^1
>
> On 8/26/19 12:04 PM, Martin Liška wrote:
> > Ok. I have a semi-working patch that has issues for inline clones.
> > When we call cgraph_node::get_untransformed_body for an inline clone,
> > then one needs to use clone_of->order to find proper LTO stream.
This seems OK to me - when us
PING^1
On 8/26/19 12:04 PM, Martin Liška wrote:
> Ok. I have a semi-working patch that has issues for inline clones.
> When we call cgraph_node::get_untransformed_body for an inline clone,
> then one needs to use clone_of->order to find proper LTO stream.
>
> What's more problematic is that such
Ok. I have a semi-working patch that has issues for inline clones.
When we call cgraph_node::get_untransformed_body for an inline clone,
then one needs to use clone_of->order to find proper LTO stream.
What's more problematic is that such clone can be expanded:
f/12 (f) @0x7769f708
Type: fu
>
> Sorry, I mean the hash which we use in LGEN even now. So e.g.:
>
> readelf -S -W main.o
> There are 17 section headers, starting at offset 0x958:
>
> Section Headers:
> [Nr] Name TypeAddress OffSize ES
> Flg Lk Inf Al
> ...
> [ 6] .gnu.lto_main.e4
On 8/23/19 5:05 PM, Jan Hubicka wrote:
>> On 8/23/19 4:37 PM, Jan Hubicka wrote:
On 8/23/19 2:33 PM, Martin Liška wrote:
> So in WPA, we shift order by order_base. For streaming purpose I'll need
> something like symtab_node::lgen_order that will be streamer_read_hwi
> (ib).
> On 8/23/19 4:37 PM, Jan Hubicka wrote:
> >> On 8/23/19 2:33 PM, Martin Liška wrote:
> >>> So in WPA, we shift order by order_base. For streaming purpose I'll need
> >>> something like symtab_node::lgen_order that will be streamer_read_hwi
> >>> (ib).
> >>
> >> And we'll probably need to stream t
On 8/23/19 4:37 PM, Jan Hubicka wrote:
>> On 8/23/19 2:33 PM, Martin Liška wrote:
>>> So in WPA, we shift order by order_base. For streaming purpose I'll need
>>> something like symtab_node::lgen_order that will be streamer_read_hwi (ib).
>>
>> And we'll probably need to stream the original LGEN sy
> On 8/23/19 2:33 PM, Martin Liška wrote:
> > So in WPA, we shift order by order_base. For streaming purpose I'll need
> > something like symtab_node::lgen_order that will be streamer_read_hwi (ib).
>
> And we'll probably need to stream the original LGEN symtab_node::order
> in order to read prope
On 8/23/19 2:33 PM, Martin Liška wrote:
> So in WPA, we shift order by order_base. For streaming purpose I'll need
> something like symtab_node::lgen_order that will be streamer_read_hwi (ib).
And we'll probably need to stream the original LGEN symtab_node::order
in order to read proper section du
On 8/15/19 4:33 PM, Jan Hubicka wrote:
>> On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
>>>
>>> Hi.
>>>
>>> The patch is about prevention of LTO section name clashing.
>>> Now we have a situation where body of 2 functions is streamed
>>> into the same ELF section. Then we'll end up with smash
On Thu, Aug 15, 2019 at 4:33 PM Jan Hubicka wrote:
>
> > On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
> > >
> > > Hi.
> > >
> > > The patch is about prevention of LTO section name clashing.
> > > Now we have a situation where body of 2 functions is streamed
> > > into the same ELF section.
> On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
> >
> > Hi.
> >
> > The patch is about prevention of LTO section name clashing.
> > Now we have a situation where body of 2 functions is streamed
> > into the same ELF section. Then we'll end up with smashed data.
> >
> > Patch can bootstrap on
On Mon, Aug 12, 2019 at 12:49 PM Richard Biener
wrote:
>
> On Mon, Aug 12, 2019 at 12:43 PM Martin Liška wrote:
> >
> > On 8/12/19 12:39 PM, Richard Biener wrote:
> > > which is the "other" body for 'open' but it shouldn't really be output
> > > to the symbol table. Still we want to emit its bod
On Mon, Aug 12, 2019 at 12:43 PM Martin Liška wrote:
>
> On 8/12/19 12:39 PM, Richard Biener wrote:
> > which is the "other" body for 'open' but it shouldn't really be output
> > to the symbol table. Still we want to emit its body for the purpose
> > of inlining. So IMHO the fix is not to do mag
On Mon, Aug 12, 2019 at 12:39 PM Richard Biener
wrote:
>
> On Mon, Aug 12, 2019 at 11:57 AM Martin Liška wrote:
> >
> > On 8/12/19 11:45 AM, Richard Biener wrote:
> > > On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
> > >>
> > >> Hi.
> > >>
> > >> The patch is about prevention of LTO section
On 8/12/19 12:39 PM, Richard Biener wrote:
> which is the "other" body for 'open' but it shouldn't really be output
> to the symbol table. Still we want to emit its body for the purpose
> of inlining. So IMHO the fix is not to do magic '0' appending for
> the user-asm-name case but instead "mangl
On Mon, Aug 12, 2019 at 11:57 AM Martin Liška wrote:
>
> On 8/12/19 11:45 AM, Richard Biener wrote:
> > On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about prevention of LTO section name clashing.
> >> Now we have a situation where body of 2 functions is
On 8/12/19 11:45 AM, Richard Biener wrote:
> On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
>>
>> Hi.
>>
>> The patch is about prevention of LTO section name clashing.
>> Now we have a situation where body of 2 functions is streamed
>> into the same ELF section. Then we'll end up with smashed
On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
>
> Hi.
>
> The patch is about prevention of LTO section name clashing.
> Now we have a situation where body of 2 functions is streamed
> into the same ELF section. Then we'll end up with smashed data.
>
> Patch can bootstrap on x86_64-linux-gnu a
Hi.
The patch is about prevention of LTO section name clashing.
Now we have a situation where body of 2 functions is streamed
into the same ELF section. Then we'll end up with smashed data.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Mart
26 matches
Mail list logo
