On 2018-12-04 7:48 a.m., Martin Jambor wrote:
> Hi,
>
> On Tue, Sep 04 2018, Michael Ploujnikov wrote:
>>
>> I've tried building with numbered_clone_function_name replaced by
>> suffixed_function_name and with --enable-offload-targets=hsa and
>> didn't see any errors in gomp.exp. I don't have a re
Hi,
On Tue, Sep 04 2018, Michael Ploujnikov wrote:
>
> I've tried building with numbered_clone_function_name replaced by
> suffixed_function_name and with --enable-offload-targets=hsa and
> didn't see any errors in gomp.exp. I don't have a readily available
> HSA setup so if you could do a quick t
Hi Martin,
On 2018-09-03 06:01 AM, Martin Jambor wrote:
> Hi,
>
> On Fri, Aug 31 2018, Michael Ploujnikov wrote:
>> I've done some more digging into the current uses of
>> numbered_clone_function_name and checked if any tests fail if I change
>> it to suffixed_function_name:
>>
>> - gcc/cgraphc
Hi Martin, Richard,
Thanks for your responses.
On 2018-09-03 09:15 AM, Martin Jambor wrote:
> Hi,
>
> On Mon, Sep 03 2018, Richard Biener wrote:
>> On Mon, Sep 3, 2018 at 12:02 PM Martin Jambor wrote:
>>>
>>> Hi,
>>>
>>> On Fri, Aug 31 2018, Michael Ploujnikov wrote:
I've done some more di
Hi,
On Mon, Sep 03 2018, Richard Biener wrote:
> On Mon, Sep 3, 2018 at 12:02 PM Martin Jambor wrote:
>>
>> Hi,
>>
>> On Fri, Aug 31 2018, Michael Ploujnikov wrote:
>> > I've done some more digging into the current uses of
>> > numbered_clone_function_name and checked if any tests fail if I chang
On Mon, Sep 3, 2018 at 12:02 PM Martin Jambor wrote:
>
> Hi,
>
> On Fri, Aug 31 2018, Michael Ploujnikov wrote:
> > I've done some more digging into the current uses of
> > numbered_clone_function_name and checked if any tests fail if I change
> > it to suffixed_function_name:
> >
> > - gcc/cgra
Hi,
On Fri, Aug 31 2018, Michael Ploujnikov wrote:
> I've done some more digging into the current uses of
> numbered_clone_function_name and checked if any tests fail if I change
> it to suffixed_function_name:
>
> - gcc/cgraphclones.c: DECL_NAME (new_decl) = numbered_clone_function_name
> (th
On 2018-08-13 07:58 PM, Michael Ploujnikov wrote:
> Ping and I've updated the patch since last time as follows:
>
> - unittest scans assembly rather than the constprop dump because its
> forward changed
> - unittests should handle different hosts where any of
> NO_DOT_IN_LABEL, NO_DOLL
On 08/13/2018 05:58 PM, Michael Ploujnikov wrote:
> Ping and I've updated the patch since last time as follows:
>
> - unittest scans assembly rather than the constprop dump because its
> forward changed
> - unittests should handle different hosts where any of
> NO_DOT_IN_LABEL, NO_DOLL
Ping and I've updated the patch since last time as follows:
- unittest scans assembly rather than the constprop dump because its
forward changed
- unittests should handle different hosts where any of
NO_DOT_IN_LABEL, NO_DOLLAR_IN_LABEL or __USER_LABEL_PREFIX__ may
be defined
- no
On 2018-08-01 06:37 AM, Richard Biener wrote:
> On Tue, Jul 31, 2018 at 7:40 PM Michael Ploujnikov
> wrote:
>>
>> On 2018-07-26 01:27 PM, Michael Ploujnikov wrote:
>>> On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
On 2018-07-20 06:05 AM, Richard Biener wrote:
>> /* Return a new assem
On Tue, Jul 31, 2018 at 7:40 PM Michael Ploujnikov
wrote:
>
> On 2018-07-26 01:27 PM, Michael Ploujnikov wrote:
> > On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
> >> On 2018-07-20 06:05 AM, Richard Biener wrote:
> /* Return a new assembler name for a clone with SUFFIX of a decl named
>
On 2018-07-26 01:27 PM, Michael Ploujnikov wrote:
> On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
>> On 2018-07-20 06:05 AM, Richard Biener wrote:
/* Return a new assembler name for a clone with SUFFIX of a decl named
NAME. */
@@ -521,14 +521,13 @@ tree
clone_function
On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
> On 2018-07-20 06:05 AM, Richard Biener wrote:
>>> /* Return a new assembler name for a clone with SUFFIX of a decl named
>>> NAME. */
>>> @@ -521,14 +521,13 @@ tree
>>> clone_function_name_1 (const char *name, const char *suffix)
>>
>> pass
On 2018-07-20 06:05 AM, Richard Biener wrote:
> On Fri, Jul 20, 2018 at 4:48 AM Michael Ploujnikov
> wrote:
>>
>> On 2018-07-17 04:25 PM, Michael Ploujnikov wrote:
>>> On 2018-07-17 06:02 AM, Richard Biener wrote:
On Tue, Jul 17, 2018 at 8:10 AM Bernhard Reutner-Fischer
wrote:
>
>>>
On Fri, Jul 20, 2018 at 4:48 AM Michael Ploujnikov
wrote:
>
> On 2018-07-17 04:25 PM, Michael Ploujnikov wrote:
> > On 2018-07-17 06:02 AM, Richard Biener wrote:
> >> On Tue, Jul 17, 2018 at 8:10 AM Bernhard Reutner-Fischer
> >> wrote:
> >>>
> >>> On 16 July 2018 21:38:36 CEST, Michael Ploujnikov
On 2018-07-17 04:25 PM, Michael Ploujnikov wrote:
> On 2018-07-17 06:02 AM, Richard Biener wrote:
>> On Tue, Jul 17, 2018 at 8:10 AM Bernhard Reutner-Fischer
>> wrote:
>>>
>>> On 16 July 2018 21:38:36 CEST, Michael Ploujnikov
>>> wrote:
Hi,
>>>
+clone_fn_ids = hash_map::create
On 2018-07-17 06:02 AM, Richard Biener wrote:
> On Tue, Jul 17, 2018 at 8:10 AM Bernhard Reutner-Fischer
> wrote:
>>
>> On 16 July 2018 21:38:36 CEST, Michael Ploujnikov
>> wrote:
>>> Hi,
>>>
>>
>>> +clone_fn_ids = hash_map::create_ggc
>>> (1000);
>>
>> Isn't 1000 a bit excessive? What about
On Tue, Jul 17, 2018 at 8:10 AM Bernhard Reutner-Fischer
wrote:
>
> On 16 July 2018 21:38:36 CEST, Michael Ploujnikov
> wrote:
> >Hi,
> >
>
> >+clone_fn_ids = hash_map::create_ggc
> >(1000);
>
> Isn't 1000 a bit excessive? What about 64 or thereabouts?
I'm not sure we should throw memory at
On 16 July 2018 21:38:36 CEST, Michael Ploujnikov
wrote:
>Hi,
>
>+clone_fn_ids = hash_map::create_ggc
>(1000);
Isn't 1000 a bit excessive? What about 64 or thereabouts?
thanks,
Hi,
This patch is a small part of the work I'm doing to make function
codegen/assembly independent from one another as mentioned in:
https://gcc.gnu.org/ml/gcc/2018-07/msg00210.html. It deals with clone_fn_id_num
rather than object UIDs and I figured it's better to make my first submission
wit
21 matches
Mail list logo
