llvm dev - Jan 2016 - [GlobalISel][RFC] Thoughts on MachineModulePass

Hi,

In the initial thread of the proposal for GlobalISel, I have mentioned that it
may be interesting to have a kind of MachineModulePass.
Marcello mentioned this would be useful for their current pipeline.

I am interested in knowing:
1. If anyone else is interested for such concept?
2. What kind of information should we make accessible in an hypothetical
MachineModule? I.e., how do you plan to use the MachineModulePass so that we
make the right design decisions for the MachineModule feeding those passes?
3. Who would be willing to work on that?

Thanks,
-Quentin

On 1/22/16 6:16 PM, Quentin Colombet via llvm-dev wrote:
> Hi,
>
> In the initial thread of the proposal for GlobalISel, I have mentioned that
it may be interesting to have a kind of MachineModulePass.
> Marcello mentioned this would be useful for their current pipeline.
>
> I am interested in knowing:
> 1. If anyone else is interested for such concept?
> 2. What kind of information should we make accessible in an hypothetical
MachineModule? I.e., how do you plan to use the MachineModulePass so that we
make the right design decisions for the MachineModule feeding those passes?
> 3. Who would be willing to work on that?
Nearly perfect timing.  I just wrote a grant proposal requesting funding 
to do just such a thing.
:)

My research group is interested in a MachineModulePass because we are 
using LLVM's MachineInstr infrastructure for analyzing machine code.  
Specifically, we are attempting to build an infrastructure for measuring 
how well various defenses work against code reuse attacks.  We are 
analyzing both data flow and control flow, and it would be handy for us 
to be able to analyze an entire program's assembly code (because we're 
looking for every last reusable instruction that an attacker could use 
and how those instructions can be strung together).  We want to analyze 
after everything has been done (register allocation, instruction 
selection and scheduling, etc.).

At the very least, we'll be doing analysis, though it is conceivable 
that we would want to do transformation in the future (e.g., if we can 
determine that breaking certain data flows would stop an attack, we 
could transform the code to change the data flow).

Ethan, can you add anything more specific on what would be on our wish list?

As for resources, we're currently early enough in the project that we're
not needing the inter-procedural analysis, and if we do need it, it may 
be quicker for us to hack something together than to enhance LLVM 
properly.  The point of the proposal is to seek additional funding so 
that we could afford to do things properly instead of just hacking 
something together just to meet our own research needs.  That said, if 
we makes sense to join forces, we'd certainly be open to doing that.

Regards,

John Criswell
>
> Thanks,
> -Quentin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

> On Jan 22, 2016, at 15:16, Quentin Colombet via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 1. If anyone else is interested for such concept?
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/7fb3ffce/attachment.html>

The pass, the perspective of our use case, would need to be able some kind of
synchronization point in the pipeline between MF passes (such that all the MF
passes before have run on all the MachineFunctions in the Module before running
the MachineModule pass)
Currently the MachineFunctions are processed from the beginning to the end
making it difficult to be able to do Machine level analysis without awful tricks
(where we get information from multiple functions and merge them together in
some way).
Immutable passes would also need to be accessible.

An important design decision would be to understand what can and cannot a
MachineModulePass do to a hypotetical MachineModule (can it add MachineFunctions
that are not connected to IR machine functions like a MachineFunction pass can
add MachineBasicBlocks not connected to IR BasicBlocks?)

Marcello
> On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at apple.com>
wrote:
> 
> Hi,
> 
> In the initial thread of the proposal for GlobalISel, I have mentioned that
it may be interesting to have a kind of MachineModulePass.
> Marcello mentioned this would be useful for their current pipeline.
> 
> I am interested in knowing:
> 1. If anyone else is interested for such concept?
> 2. What kind of information should we make accessible in an hypothetical
MachineModule? I.e., how do you plan to use the MachineModulePass so that we
make the right design decisions for the MachineModule feeding those passes?
> 3. Who would be willing to work on that?
> 
> Thanks,
> -Quentin

Hi Marcello,

Can you elaborate here a bit more? Mostly what it sounds like is just a
direct port of Module pass to run over MFs, similar to what AsmPrinter does
today, but also being able to have some analysis passes as well?

I realize my question seems a bit vague, but I'm trying to get a better
idea of what the use case is here as it sounds like something that we could
have the "MF pipeline" have and use and be (possibly) a better place
to
stick the AsmPrinter (we'd need to figure out things like globals, but that
might be it).

Thanks!

-eric

On Fri, Jan 22, 2016 at 10:44 PM Marcello Maggioni via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The pass, the perspective of our use case, would need to be able some kind
> of synchronization point in the pipeline between MF passes (such that all
> the MF passes before have run on all the MachineFunctions in the Module
> before running the MachineModule pass)
> Currently the MachineFunctions are processed from the beginning to the end
> making it difficult to be able to do Machine level analysis without awful
> tricks (where we get information from multiple functions and merge them
> together in some way).
> Immutable passes would also need to be accessible.
>
> An important design decision would be to understand what can and cannot a
> MachineModulePass do to a hypotetical MachineModule (can it add
> MachineFunctions that are not connected to IR machine functions like a
> MachineFunction pass can add MachineBasicBlocks not connected to IR
> BasicBlocks?)
>
> Marcello
>
> > On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at
apple.com> wrote:
> >
> > Hi,
> >
> > In the initial thread of the proposal for GlobalISel, I have mentioned
> that it may be interesting to have a kind of MachineModulePass.
> > Marcello mentioned this would be useful for their current pipeline.
> >
> > I am interested in knowing:
> > 1. If anyone else is interested for such concept?
> > 2. What kind of information should we make accessible in an
hypothetical
> MachineModule? I.e., how do you plan to use the MachineModulePass so that
> we make the right design decisions for the MachineModule feeding those
> passes?
> > 3. Who would be willing to work on that?
> >
> > Thanks,
> > -Quentin
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20160123/e7f3ca29/attachment.html>

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
John
> Criswell via llvm-dev
> Sent: Friday, January 22, 2016 9:39 PM
> To: Quentin Colombet <qcolombet at apple.com>; llvm-dev <llvm-
> dev at lists.llvm.org>; Ethan Johnson <ethanjohnson89 at
gmail.com>
> Subject: Re: [llvm-dev] [GlobalISel][RFC] Thoughts on MachineModulePass
> 
> On 1/22/16 6:16 PM, Quentin Colombet via llvm-dev wrote:
> > Hi,
> >
> > In the initial thread of the proposal for GlobalISel, I have mentioned
that
> it may be interesting to have a kind of MachineModulePass.
> > Marcello mentioned this would be useful for their current pipeline.
> >
> > I am interested in knowing:
> > 1. If anyone else is interested for such concept?
> > 2. What kind of information should we make accessible in an
hypothetical
> MachineModule? I.e., how do you plan to use the MachineModulePass so that
we
> make the right design decisions for the MachineModule feeding those passes?
> > 3. Who would be willing to work on that?
> 
> Nearly perfect timing.  I just wrote a grant proposal requesting funding
> to do just such a thing.
> :)
> 
> My research group is interested in a MachineModulePass because we are
> using LLVM's MachineInstr infrastructure for analyzing machine code.
> Specifically, we are attempting to build an infrastructure for measuring
> how well various defenses work against code reuse attacks.  We are
> analyzing both data flow and control flow, and it would be handy for us
> to be able to analyze an entire program's assembly code (because
we're
> looking for every last reusable instruction that an attacker could use
> and how those instructions can be strung together).  We want to analyze
> after everything has been done (register allocation, instruction
> selection and scheduling, etc.).
> 
> At the very least, we'll be doing analysis, though it is conceivable
> that we would want to do transformation in the future (e.g., if we can
> determine that breaking certain data flows would stop an attack, we
> could transform the code to change the data flow).
> 
> Ethan, can you add anything more specific on what would be on our wish
list?
The main thing that comes to mind is that it would be useful to have access to
call graph information at the machine code level. Since this is already being
tracked at the IR level, a lot of that information could probably be
"inherited" by a MachineModule during code generation.

In particular, taking advantage of LLVM's "inside knowledge" about
the semantics of call instructions would be helpful in identifying the targets
of indirect calls. Right now, the only way to determine the target of a
machine-level call is to look at the instruction's operands, and if any of
them refer to globals, try to dyn_cast them to a Function. This, of course, only
works for direct calls. For indirect calls, the best we could do is try to use
data-flow analysis to determine what's in the pointer being called, and
attempt to match that to the known address of a MachineFunction. As I understand
it (and please correct me if I'm wrong), the existing IR-level call graph
analysis already "knows" where the function pointer came from (unless
the code is calling a "wild" function pointer created through an
unsafe cast, but that's another story).

Ethan Johnson
> 
> As for resources, we're currently early enough in the project that
we're
> not needing the inter-procedural analysis, and if we do need it, it may
> be quicker for us to hack something together than to enhance LLVM
> properly.  The point of the proposal is to seek additional funding so
> that we could afford to do things properly instead of just hacking
> something together just to meet our own research needs.  That said, if
> we makes sense to join forces, we'd certainly be open to doing that.
> 
> Regards,
> 
> John Criswell
> 
> >
> > Thanks,
> > -Quentin
>

On 01/22/2016 03:16 PM, Quentin Colombet via llvm-dev
wrote:
> Hi,
>
> In the initial thread of the proposal for GlobalISel, I have mentioned that
it may be interesting to have a kind of MachineModulePass.
> Marcello mentioned this would be useful for their current pipeline.
>
> I am interested in knowing:
> 1. If anyone else is interested for such concept?
> 2. What kind of information should we make accessible in an hypothetical
MachineModule? I.e., how do you plan to use the MachineModulePass so that we
make the right design decisions for the MachineModule feeding those passes?
> 3. Who would be willing to work on that?
This could be interested from a GC perspective.  The current RS4GC pass 
which exists as an IR to IR transform would be (potentially) nice to 
push back into the backend.  It's inherently a module level pass, so 
having an MI layer equivalent could be useful.  Note that I'm not saying 
"required" or even "definitely useful"; I suspect we can
find a
practical engineering compromise today by splitting RS4GC into two or 
more pieces that run at different times.

Also, just an FYI, we already have Module level analysis passes over MI, 
but only the immutable variety.  One of those is used by the gc.root 
infrastructure.  See GCModuleInfo.
>
> Thanks,
> -Quentin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Fri, Jan 22, 2016 at 3:16 PM, Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> In the initial thread of the proposal for GlobalISel, I have mentioned
> that it may be interesting to have a kind of MachineModulePass.
> Marcello mentioned this would be useful for their current pipeline.
>
> I am interested in knowing:
> 1. If anyone else is interested for such concept?
> 2. What kind of information should we make accessible in an hypothetical
> MachineModule? I.e., how do you plan to use the MachineModulePass so that
> we make the right design decisions for the MachineModule feeding those
> passes?
>
In an LTO context with most functions internalized, aggressively changing
calling conventions in a fine-grained way would be interesting (or, in
other words, doing some amount of interprocedural register allocation).

-- Sean Silva

> 3. Who would be willing to work on that?
>
> Thanks,
> -Quentin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20160125/6c55a8e6/attachment.html>

On 1/22/2016 5:16 PM, Quentin Colombet via llvm-dev
wrote:
>
> 1. If anyone else is interested for such concept?
I think it would be useful to be able to modify the module after the 
machine instructions have been selected.  I don't have any specific 
examples that would demonstrate the need for it, but being able to 
create functions/globals from the MI level may come in handy.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation