>>Can't you get the loader fixed, instead?
Yes we are thinking the same ,question what should be loader semantics here
(update the prologue code to update r12 to Global Entry Point or Update R2
with toc base (that don't relay on the R12). )
~Umesh
On Thu, May 16, 2019, 05:22 Segher Boessenkool
wr
Hi devs,
I am looking into subjected issue.
consider below testcase.
$test.cpp
class A {
public:
virtual int value() { return 1; }
};
class B final : public A {
public:
int value(){ return 2; }
};
int test(A* b) {
return b->value() + 11;
}
void foo_test(B*b)
{
test(b);
}
Here gcc is u
On Wed, May 15, 2019 at 08:31:27PM +0200, Eric Botcazou wrote:
> > Thank you Eric for the suggestion and say that we support in the loader
> > part ,can you please point on elfv2 reference that says implementation for
> > this specific case.
>
> I don't think there is a reference to this specific
Hi Umesh,
Please spell out "global entry point", almost everything and everyone does.
On Wed, May 15, 2019 at 08:57:29PM +0530, Umesh Kalappa wrote:
> .set.LTHUNK0,_ZN12Intermediate1vEv
> _ZThn8_N12Intermediate1vEv:
> .LCF2:
> 0: addis 2,12,.TOC.-.LCF2@ha
> addi 2,2,.TO
> Thank you Eric for the suggestion and say that we support in the loader
> part ,can you please point on elfv2 reference that says implementation for
> this specific case.
I don't think there is a reference to this specific case in the ABI, only the
general stuff about local and global entry po
On 5/15/19 1:01 PM, Jakub Jelinek wrote:
> On Wed, May 15, 2019 at 12:59:01PM -0500, Aaron Sawdey wrote:
>> 1) rename optab movmem and the underlying patterns to cpymem.
>> 2) add a new optab movmem that is really memmove() and add support for
>> having __builtin_memmove() use it.
>>
>> Handling of
On Wed, May 15, 2019 at 12:59:01PM -0500, Aaron Sawdey wrote:
> On 5/15/19 11:31 AM, Jakub Jelinek wrote:
> > On Wed, May 15, 2019 at 11:23:54AM -0500, Aaron Sawdey wrote:
> >> My goals for this are:
> >> * memcpy() call becomes __builtin_memcpy and goes to optab[cpymem]
> >> * memmove() call bec
On 5/15/19 11:31 AM, Jakub Jelinek wrote:
> On Wed, May 15, 2019 at 11:23:54AM -0500, Aaron Sawdey wrote:
>> My goals for this are:
>> * memcpy() call becomes __builtin_memcpy and goes to optab[cpymem]
>> * memmove() call becomes __builtin_memmove (or __builtin_memcpy based
>>on the gimple an
Thank you Eric for the suggestion and say that we support in the loader
part ,can you please point on elfv2 reference that says implementation for
this specific case.
~Umesh
On Wed, May 15, 2019, 21:35 Eric Botcazou wrote:
> > like above the control from "_ZThn8_N12Intermediate1vEv" (support
On Wed, May 15, 2019 at 11:23:54AM -0500, Aaron Sawdey wrote:
> We currently have gimple_fold_builtin_memory_op() figuring out where there
> is no overlap and converging __builtin_memmove() to __builtin_memcpy(). Would
> you forsee looking for converting __builtin_memmove() with overlap into
> a ca
On 5/15/19 9:02 AM, Michael Matz wrote:
> On Wed, 15 May 2019, Aaron Sawdey wrote:
>> Next question would be how do we move from the existing movmem pattern
>> (which Michael Matz tells us should be renamed cpymem anyway) to this
>> new thing. Are you proposing that we still have both movmem and
> like above the control from "_ZThn8_N12Intermediate1vEv" (support
> function for this pointer update) is transferred
> "_ZN12Intermediate1vEv" by b inst (where its not updating the r12)
> and in the beginning of "_ZN12Intermediate1vEv" we are loading the
> toc base from r12 (which is incorr
Hi All,
We have the situation ,where the R12 is pointing to Thunk GEP ,not the
current function like
.size _ZN12Intermediate1vEv,.-_ZN12Intermediate1vEv
.set.LTHUNK0,_ZN12Intermediate1vEv
.align 2
.globl _ZThn8_N12Intermediate1vEv
.type _ZThn8_N12In
Hi,
On Wed, 15 May 2019, Jakub Jelinek wrote:
> Just one thing to note, our "memcpy" expectation is that either there is
> no overlap, or there is 100% overlap (src == dest), both all the current
> movmem == future cpymem expanders and all the supported library
> implementations do support tha
On Wed, May 15, 2019 at 02:02:32PM +, Michael Matz wrote:
> > Yes this would be a nice thing to get to, a single move/copy underlying
> > builtin, to which we communicate what the compiler's analysis tells us
> > about whether the operands overlap and by how much.
> >
> > Next question would
Hi,
On Wed, 15 May 2019, Aaron Sawdey wrote:
> Yes this would be a nice thing to get to, a single move/copy underlying
> builtin, to which we communicate what the compiler's analysis tells us
> about whether the operands overlap and by how much.
>
> Next question would be how do we move from t
On 5/15/19 7:22 AM, Richard Biener wrote:
> On Tue, May 14, 2019 at 9:21 PM Aaron Sawdey wrote:
>> I'd be interested in any comments about pieces of this machinery that need to
>> work a certain way, or other related issues that should be addressed in
>> between expand_builtin_memcpy() and emit_bl
On 5/15/19 8:10 AM, Michael Matz wrote:> On Tue, 14 May 2019, Aaron Sawdey
wrote:
>
>> memcpy -> expand with movmem pattern
>> memmove (no overlap) -> transform to memcpy -> expand with movmem pattern
>> memmove (overlap) -> remains memmove -> glibc call
> ...
>> However in builtins.c expand_buil
Hi,
On Tue, 14 May 2019, Aaron Sawdey wrote:
> memcpy -> expand with movmem pattern
> memmove (no overlap) -> transform to memcpy -> expand with movmem pattern
> memmove (overlap) -> remains memmove -> glibc call
...
> However in builtins.c expand_builtin_memmove() does not actually do the
> exp
On Tue, May 14, 2019 at 9:21 PM Aaron Sawdey wrote:
>
> GCC does not currently do inline expansion of overlapping memmove, nor does it
> have an expansion pattern to allow for non-overlapping memcpy, so I plan to
> add
> patterns and support to implement this in gcc 10 timeframe.
>
> At present m
On Wed, May 15, 2019 at 2:23 PM Martin Liška wrote:
> On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> > void func_1();
> > void func_3();
> > .
> >
> > void foo1() __attribute__ ((weak, alias("func_1")));
> > void foo3() __attribute__ ((weak, alias("func_3")));
>
> Hi.
>
> In all emails that yo
On Wed, May 15, 2019 at 2:13 PM Martin Liška wrote:
> On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> > Hello Martin and community,
>
> Hi Shubham.
>
> Thank you for starting working on the project. There are some
> recommendations
> before we fully being:
>
> 1) I've recently received 5 emails tha
On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> void func_1();
> void func_3();
> .
>
> void foo1() __attribute__ ((weak, alias("func_1")));
> void foo3() __attribute__ ((weak, alias("func_3")));
Hi.
In all emails that you sent there's no patch that will implement 'alias'
attribute.
Thanks,
On 5/15/19 10:12 AM, Shubham Narlawar wrote:
> Hello Martin and community,
>
> Below is attached patch for Function Attribute Aligned -
>
> The command line option to generate aligned attribute is -
> --func-attr-aligned which can be found in ./csmith --help
>
> Please review the patch and sugge
On 5/15/19 9:49 AM, Shubham Narlawar wrote:
> Hello Martin and community,
Hi Shubham.
Thank you for starting working on the project. There are some recommendations
before we fully being:
1) I've recently received 5 emails that have very similar subject and it's
unclear why that happened? When
25 matches
Mail list logo
