Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

> >>> I think this remapping should happen with `file-prefix-map` but > >>> shouldn't with `debug-prefix-map` (though if it happens for both it's > >>> also not too bad) and I believe this patch is the minimum change to > >>> achieve that. I think it makes sense to make this follow > >>> `macro-pre

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

> > > I think this remapping should happen with `file-prefix-map` but > > > shouldn't with `debug-prefix-map` (though if it happens for both it's > > > also not too bad) and I believe this patch is the minimum change to > > > achieve that. I think it makes sense to make this follow > > > `macro-pre

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

Forwarding to fort...@gcc.gnu.org as suggested by Dominique d'Humieres. On Sun, Jul 5, 2020 at 9:29 PM Yichao Yu wrote: > > > I think this remapping should happen with `file-prefix-map` but > > shouldn't with `debug-prefix-map` (though if it happens for both it's > > also not too bad) and I belie

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

> I think this remapping should happen with `file-prefix-map` but > shouldn't with `debug-prefix-map` (though if it happens for both it's > also not too bad) and I believe this patch is the minimum change to > achieve that. I think it makes sense to make this follow > `macro-prefix-map` although I'

[PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

Sorry I think I accidentally had rich text mode on and also forgot the `[PATCH]` in the title in the previous email... Try again... Currently this is using the macro prefix map without allowing the -fmacro-prefix-map argument, which is arguably pretty weird... but I don't know what would be a bett

Map filename from print in gfortran with -ffile-prefix-map (PR96069)

Currently this is using the macro prefix map without allowing the ---fmacro-prefix-map argument, which is arguably pretty weird... but I don't know what would be a better way. I think this remapping should happen with `file-prefix-map` but shouldn't with `debug-prefix-map` (though if it happens fo

Re: [PATCH] Fix target clone indirection elimination.

On Fri, Jun 26, 2020 at 5:51 PM Jeff Law wrote: > > On Mon, 2020-06-22 at 11:24 +0200, Richard Biener via Gcc-patches wrote: > > On Sun, Jun 21, 2020 at 2:32 AM Yichao Yu via Gcc-patches > > wrote: > > > On Sat, Jun 20, 2020 at 8:16 PM Yichao Yu wrote: > > &g

Re: [PATCH] Fix target clone indirection elimination.

On Sat, Jun 20, 2020 at 8:16 PM Yichao Yu wrote: > > On Sat, Jun 20, 2020 at 3:41 PM Yichao Yu wrote: > > > > On Sat, Jun 20, 2020 at 3:26 PM Yichao Yu wrote: > > > > > > On Sat, Jun 20, 2020 at 3:25 PM H.J. Lu wrote: > > > > > > > > On Sat, Jun 20, 2020 at 12:20 PM Yichao Yu wrote: > > > > >

Re: [PATCH] Fix target clone indirection elimination.

On Sat, Jun 20, 2020 at 3:41 PM Yichao Yu wrote: > > On Sat, Jun 20, 2020 at 3:26 PM Yichao Yu wrote: > > > > On Sat, Jun 20, 2020 at 3:25 PM H.J. Lu wrote: > > > > > > On Sat, Jun 20, 2020 at 12:20 PM Yichao Yu wrote: > > > > > > > > On Sat, Jun 20, 2020 at 3:12 PM H.J. Lu wrote: > > > > > >

Re: [PATCH] Fix target clone indirection elimination.

On Sat, Jun 20, 2020 at 3:26 PM Yichao Yu wrote: > > On Sat, Jun 20, 2020 at 3:25 PM H.J. Lu wrote: > > > > On Sat, Jun 20, 2020 at 12:20 PM Yichao Yu wrote: > > > > > > On Sat, Jun 20, 2020 at 3:12 PM H.J. Lu wrote: > > > > > > > > On Sat, Jun 20, 2020 at 11:37 AM Yichao Yu wrote: > > > > > >

Re: [PATCH] Fix target clone indirection elimination.

On Sat, Jun 20, 2020 at 3:25 PM H.J. Lu wrote: > > On Sat, Jun 20, 2020 at 12:20 PM Yichao Yu wrote: > > > > On Sat, Jun 20, 2020 at 3:12 PM H.J. Lu wrote: > > > > > > On Sat, Jun 20, 2020 at 11:37 AM Yichao Yu wrote: > > > > > > > > On Sat, Jun 20, 2020 at 1:54 PM Yichao Yu wrote: > > > > > >

Re: [PATCH] Fix target clone indirection elimination.

On Sat, Jun 20, 2020 at 3:12 PM H.J. Lu wrote: > > On Sat, Jun 20, 2020 at 11:37 AM Yichao Yu wrote: > > > > On Sat, Jun 20, 2020 at 1:54 PM Yichao Yu wrote: > > > > > > > > The current logic seems to be comparing the whole attribute tree > > > > > between the callee > > > > > and caller (or at

Re: [PATCH] Fix target clone indirection elimination.

> https://github.com/gcc-mirror/gcc/commit/b8ce8129a560f64f8b2855c4a3812b7c3c0ebf3f#diff-e2d535917af8555baad2e9c8749e96a5 > with/adding to the test the following one should work. I still > couldn't get test to run though.. And yet another related issue that I think I would appreciate some help

Re: [PATCH] Fix target clone indirection elimination.

On Sat, Jun 20, 2020 at 1:54 PM Yichao Yu wrote: > > > > The current logic seems to be comparing the whole attribute tree between > > > the callee > > > and caller (or at least the tree starting from the target attribute). > > > This is unnecessary and causes strange dependency of the indirection

Re: [PATCH] Fix target clone indirection elimination.

> > The current logic seems to be comparing the whole attribute tree between > > the callee > > and caller (or at least the tree starting from the target attribute). > > This is unnecessary and causes strange dependency of the indirection > > elimination on unrelated properties like `noinline`(PR9

[PATCH] Fix target clone indirection elimination.

The current logic seems to be comparing the whole attribute tree between the callee and caller (or at least the tree starting from the target attribute). This is unnecessary and causes strange dependency of the indirection elimination on unrelated properties like `noinline`(PR95780) and `visibili

[PATCH] Fix target clone indirection elimination (PR95778, PR95780)

The current logic seems to be comparing the whole attribute tree between the callee and caller (or at least the tree starting from the target attribute). This is unnecessary and causes strange dependency of the indirection elimination on unrelated properties like `noinline`(PR95780) and `visibi