erichkeane wrote:
> I'm not sure llvm needs to know the priorities. I haven't had time to work on
> this, but my plan was to have something that attempts to step through the
> resolver instruction by instruction with known bits for the value loaded from
> `__aarch64_cpu_features.features`
jroelofs wrote:
I'm not sure llvm needs to know the priorities. I haven't had time to work on
this, but my plan was to have something that attempts to step through the
resolver instruction by instruction with known bits for the value loaded from
`__aarch64_cpu_features.features` according to
erichkeane wrote:
I'd be OK with Clang providing some level of metadata to clarify which is an
FMV, and what our target features are. But this sort of analysis still needs
to happen in LLVM.
https://github.com/llvm/llvm-project/pull/80093
___
labrinea wrote:
@erichkeane while I agree that Clang might not be the best place for such an
optimization, I have some concerns about implementing it in LLVM:
* We cannot distinguish a FMV resolver from any other ifunc resolver.
* There is no information at the LLVM IR level about function
jroelofs wrote:
Fair. I'll give that a shot.
Doing it in opt has another big advantage I only just realized: it allows LTO
to do the transformation.
https://github.com/llvm/llvm-project/pull/80093
___
cfe-commits mailing list
https://github.com/jroelofs closed
https://github.com/llvm/llvm-project/pull/80093
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
erichkeane wrote:
> My gut feel was that recovering this information from the callee's resolver's
> body would take heroics if we tried to do it in the backend.
Opt can already see the feature strings in the llvm-attributes, and can
introspect into it for the resolver. I could PERHAPS see
jroelofs wrote:
My gut feel was that recovering this information from the callee's resolver's
body would take heroics if we tried to do it in the backend.
https://github.com/llvm/llvm-project/pull/80093
___
cfe-commits mailing list
https://github.com/jroelofs updated
https://github.com/llvm/llvm-project/pull/80093
>From ed52ee4424459ebc046a625341ad8dbbd38bcbe3 Mon Sep 17 00:00:00 2001
From: Jon Roelofs
Date: Tue, 30 Jan 2024 19:13:42 -0800
Subject: [PATCH 1/6] [clang][FMV] Direct-call multi-versioned callees from
https://github.com/erichkeane commented:
My immediate response is that this sounds like something that OPT should be
doing here, not us. We typically do NOT do this sort of thing the CFE, and do
not want to do opt-type stuff in the CFE.
Is there good reason that this isn't a part of the
https://github.com/jroelofs updated
https://github.com/llvm/llvm-project/pull/80093
>From ed52ee4424459ebc046a625341ad8dbbd38bcbe3 Mon Sep 17 00:00:00 2001
From: Jon Roelofs
Date: Tue, 30 Jan 2024 19:13:42 -0800
Subject: [PATCH 1/4] [clang][FMV] Direct-call multi-versioned callees from
https://github.com/jroelofs updated
https://github.com/llvm/llvm-project/pull/80093
>From ed52ee4424459ebc046a625341ad8dbbd38bcbe3 Mon Sep 17 00:00:00 2001
From: Jon Roelofs
Date: Tue, 30 Jan 2024 19:13:42 -0800
Subject: [PATCH 1/3] [clang][FMV] Direct-call multi-versioned callees from
https://github.com/jroelofs updated
https://github.com/llvm/llvm-project/pull/80093
>From ed52ee4424459ebc046a625341ad8dbbd38bcbe3 Mon Sep 17 00:00:00 2001
From: Jon Roelofs
Date: Tue, 30 Jan 2024 19:13:42 -0800
Subject: [PATCH 1/2] [clang][FMV] Direct-call multi-versioned callees from
https://github.com/jroelofs edited
https://github.com/llvm/llvm-project/pull/80093
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jroelofs edited
https://github.com/llvm/llvm-project/pull/80093
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
15 matches
Mail list logo
