[llvm-dev] Replace all memory access with registry access

Alberto Barbaro via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 6 22:38:21 PST 2019


Hi all,
Thanks for your help with this. I'll try what you suggested.

Appreciated

On Wed, Mar 6, 2019, 20:03 Cranmer, Joshua <joshua.cranmer at intel.com> wrote:

> What you are probably looking for are the mem2reg pass and scalar
> replacement of aggregates (SROA) pass, which includes a more aggressive
> version of mem2reg. These passes try to eliminate alloca instructions by
> converting the stack variables to registers when possible.
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Alberto
> Barbaro via llvm-dev
> *Sent:* Wednesday, March 6, 2019 14:48
> *To:* Vedant Kumar <vsk at apple.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] Replace all memory access with registry access
>
>
>
> Hi,
>
> Thanks for getting back to me. I'd like to understand if it possible to
> avoid instructions that relies on memory address and instead have all the
> necessary data inside registers. I think this would simplify a lot analysis
> on the LLVM IR..
>
>
>
> Thanks again
>
>
>
> On Wed, Mar 6, 2019, 18:23 Vedant Kumar <vsk at apple.com> wrote:
>
> Hi,
>
> Could you share some more details about what you're trying to accomplish?
>
> Generally speaking, some instructions necessarily load/store from/to
> memory (e.g. updates to a shared memory region).
>
> best,
> vedant
>
> > On Mar 6, 2019, at 9:37 AM, Alberto Barbaro via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi all,
> > Is there any way for converting any instruction that is loading or
> storing in memory into an instruction that just deal with registries?
> >
> > I'm not even sure if it is possible. Any suggestion?
> >
> > Thanks
> > _______________________________________________
> > 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/20190307/ae4540f1/attachment.html>


More information about the llvm-dev mailing list