[llvm-dev] Memory SSA for this problem?

Alina Sbirlea via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 8 13:41:50 PST 2021


Hi Riyaz,

With MemorySSA you could query clobbering on the G at the Bar callsite
using the API: `MemoryAccess *getClobberingMemoryAccess(MemoryAccess *MA,
const MemoryLocation &Loc)`, where MA is "the MemoryAccess associated with
Bar"->getDefiningAccess() and Loc is the memorylocation defining G.
If the returned clobber access dominates the load, then there are no
additional clobbering accesses between the load and the call.

Alina

On Mon, Nov 8, 2021 at 12:19 PM Riyaz Puthiyapurayil via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I am trying to figure what is the best way to do the following in LLVM.
> Specifically wonder if MemorySSA can be used here…any pointers to existing
> code that does something similar will be useful.
>
> Consider this code:
>
> %foo = load i256, i256* @G
>> possible uses of %foo
>> %bar = call i32 @Bar(i256 %foo)
>
> Now if I know that there are no writes to @G between the load and the
> call, I would like to convert the call to @Bar to a call to @BarP which
> accepts a pointer to i256:
>
> %bar = call i32 @BarP(i256* @G)
>
> How can I check if there are no clobbers of @G between the load and the
> call? @G does not alias with any other memory but there can be writes to @G
> between the above load and the call and if so, the safe thing to do is:
>
> %foop = alloca i256
> store i256 %foo, i256* %foop
>> %bar = call i32 @BarP(i256* %foop)
>
> Note that I am trying to avoid creating a copy of %foo on the stack when
> possible.
>
> The goal here is to keep the wide integer in SSA form (there is
> performance benefit in doing this) but when I have to pass the wide vector
> to a library function, I want to pass its address. Since @G may be a copy
> of %foo, I would like to pass @G instead of creating a temp with alloca
> whenever it is safe to do so. The question is how to check if @G still has
> the same value as %foo.
>
>
>
> /Riyaz
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211108/9748b5bc/attachment.html>


More information about the llvm-dev mailing list