On Thu, Aug 20, 2020 at 07:41:54PM +, Tamar Christina wrote:
> While I would agree that it's fundamentally more restrictive than an
> object based one I wouldn't say it's useless. At the very least it gives
> us something to build on later.
It is IMHO useless and has also very undesirable dir
stina
; Kevin Smith
; Gary Oblock
; Richard Biener
; Martin Jambor ; Jan
Hubicka ; Ashok Bhat ;
mli...@suse.cz; Kyrylo Tkachov
Subject: [RFC] LTO Dead Field Elimination and LTO Field Reordering
Hello again,
I have committed a couple of changes to the branch
refs/vendors/ARM/heads/arm-struct
in Smith
> ; Gary Oblock
> ; Richard Biener
> ; Martin Jambor ; Jan
> Hubicka ; Ashok Bhat ;
> mli...@suse.cz; Kyrylo Tkachov
> Subject: [RFC] LTO Dead Field Elimination and LTO Field Reordering
>
> Hello again,
>
> I have committed a couple of changes to th
Hello again,
I have committed a couple of changes to the branch
refs/vendors/ARM/heads/arm-struct-reorg-wip
where my transformations are currently residing. This week I'll be
working on fixing several warnings and fuzzying these passes.
2020-08-17 Erick Ochoa
* Can be bootstrapped
he mailing list.
This patchset adds LTO Dead Field Elimination and Field Reordering as
two different passes. I've been testing LTO Dead Field Elimination for
some time, compiling all C benchmarks in the SPEC CPU 2017 benchmarking
suite. I have not yet tested LTO Field Reordering as extensi
On 24/07/2020 17:43, Erick Ochoa wrote:
> This patchset brings back struct reorg to GCC.
>
> We’ve been working on improving cache utilization recently and would
> like to share our current implementation to receive some feedback on it.
>
> Essentially, we’ve implemented the following components:
On Mon, Jul 27, 2020 at 9:03 AM Christoph Müllner
wrote:
>
> Hi Richard,
>
> On 7/27/20 2:36 PM, Richard Biener wrote:
> > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> > wrote:
> >>
> >> This patchset brings back struct reorg to GCC.
> >>
> >> We’ve been working on improving cache utilization re
On Mon, Jul 27, 2020 at 2:59 PM Christoph Müllner
wrote:
>
> Hi Richard,
>
> On 7/27/20 2:36 PM, Richard Biener wrote:
> > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> > wrote:
> >>
> >> This patchset brings back struct reorg to GCC.
> >>
> >> We’ve been working on improving cache utilization re
On Mon, Jul 27, 2020 at 02:52:21PM +0200, Erick Ochoa wrote:
> I will work on making this more readable. I understand your comments and you
> are right. I am currently in the process of writing a human-readable PDF
> with an overview of this. There is already a (somewhat hurried) version of
> this
Hi Richard,
On 7/27/20 2:36 PM, Richard Biener wrote:
> On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
> wrote:
>>
>> This patchset brings back struct reorg to GCC.
>>
>> We’ve been working on improving cache utilization recently and would
>> like to share our current implementation to receive some
On 27/07/2020 14:36, Richard Biener wrote:
On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
wrote:
This patchset brings back struct reorg to GCC.
We’ve been working on improving cache utilization recently and would
like to share our current implementation to receive some feedback on it.
Essent
On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa
wrote:
>
> This patchset brings back struct reorg to GCC.
>
> We’ve been working on improving cache utilization recently and would
> like to share our current implementation to receive some feedback on it.
>
> Essentially, we’ve implemented the following
This patchset brings back struct reorg to GCC.
We’ve been working on improving cache utilization recently and would
like to share our current implementation to receive some feedback on it.
Essentially, we’ve implemented the following components:
Type-based escape analysis to determine if
13 matches
Mail list logo
