thr3ads.net - llvm dev - [llvm-dev] [RFC] Potential extension to asm statement functionality [Feb 2019]

If this information is useful, please help other people find it:
Share via:

Snider, Todd via llvm-dev

2019-Feb-14 17:53 UTC

[llvm-dev] [RFC] Potential extension to asm statement functionality

Hi Paul,

Regarding the "No Touchie!" constraint idea for asm statements: would
this be a new qualifier (like volatile) that could be applied to the asm
statement?
Since the constraint is not necessarily associated with an input or output
operand, it seems that introducing the constraint via the qualifier field might
work.

All,

The volatile qualifier on an asm statement already indicates that the statement
should be assumed to have side effects.
Could we extend the functionality of volatile to also mean the asm statement is
not duplicable?

~ Todd

From: Snider, Todd
Sent: Wednesday, February 13, 2019 11:40 AM
To: 'paul.robinson at sony.com'; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] [RFC] Potential extension to asm statement functionality


The proposed "lbl" constraint below:
   __asm __volatile__ ("\t.global\t%0\n%0:\n" : "lbl"
(my_hook_fcn));

is not quite a "No Touchie!" constraint, but it does allow the user to
set the isNotDuplicable flag on the INLINEASM that comes out of the asm
statement in order to circumvent optimizations like Tail Duplication.  But
setting the isNotDuplicable flag is not really enough. If the function that
contains the "lbl" constrained asm statement is inlined into a
function in the same compilation unit, the compiler will error out with a symbol
redefinition error.

We may need something on the level of a "No Touchie!" constraint.

Perhaps a new builtin function that resolves to a global label definition is a
better alternative for this use case?

~ Todd

From: paul.robinson at sony.com [mailto:paul.robinson at sony.com]
Sent: Tuesday, February 12, 2019 2:32 PM
To: Snider, Todd; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

This tactic has been tried before, I'm pretty sure.  It's an attempt to
do simple instrumentation without having to hack the compiler itself (you do
some manual coding or preprocessing, and poof you get useful info in your object
file).  But our compiler is too clever.

Some sort of "No Touchee!" constraint would help this use-case a lot.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, February 12, 2019 3:06 PM
To: Eli Friedman; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Potential extension to asm statement functionality


The team I am working with is using asm statements containing label definitions
as a way of instrumentation so that when an application is loaded into their
debug and test framework, the labels will cause breakpoints to be set at
strategic points where they can query the state of the processor that the
application is running on.

~ Todd

From: Eli Friedman [mailto:efriedma at quicinc.com]
Sent: Tuesday, February 12, 2019 1:36 PM
To: Snider, Todd; llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

Can you go into a bit more detail about why someone would want to do this, as
opposed to just writing a file scope inline asm, or a separate file in assembly?
I can't think of any practical use for the fact that the label is
"inside" the function body.

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, February 12, 2019 10:18 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] [RFC] Potential extension to asm statement
functionality


Suppose a programmer wants to inject their own global label definition into the
body of a function with some guarantee that it will not be removed by the
compiler.

One way to do this is to define a global label with an asm statement knowing
that the asm statement will not be invoked until after the compiler's
optimization passes have run, but the following case demonstrates that a label
defined with an asm statement is still susceptible to being duplicated:

#include <stdint.h>
uint32_t f(uint32_t x);
uint32_t g(uint32_t x);

uint32_t f(uint32_t x) {
    uint32_t returnValue = g(x);

    if (returnValue > 0U) {
        returnValue = 0x40000000;
    }
    else {
        returnValue = 0x80000000;
    }
    __asm __volatile__ ("\t.global my_hook_fcn\nmy_hook_fcn:\n");
    return returnValue;
}

uint32_t g(uint32_t x) {
    return x >> 1U;
}

If the above definition of f() is compiled with optimization at level 1 or
higher, the TailDuplication optimization pass will duplicate and move the asm
statement and return up into the if block and the else block before the asm
statement is invoked. When the now duplicate asm statements are later invoked,
the compiler will detect a symbol redefinition error.

To address this situation, the asm statement functionality could be extended to
comprehend whether it contains a label definition, and if it does, to disallow
duplication of the asm statement.

There are a couple of different approaches that could be taken to implement
this:

  1.  Parse the content of the assembly string argument to the asm statement in
the compiler front-end (during EmitAsmStmt(), for example) to determine if it
contains a label definition, and if it does set the isNotDuplicable flag on the
INLINEASM record that is created to represent the asm statement in the IR. To
date, there is no precedence for processing the content of the assembly string
argument until the asm statement is invoked before the integrated  assembler
starts processing the generated machine code.
  2.  Add a label constraint to the input and output operand syntax for asm
statements. i.e.
__asm __volatile__ ("\t.global\t%0\n%0:\n" : "lbl"
(my_hook_fcn));
The "lbl" constraint would tell the compiler to mark the asm statement
as isNotDuplicable when an INLINEASM record is created to represent it

There are alternatives to using an asm statement for this purpose, but I
wondered if such an extension would be useful/valuable to the wider community.

Thoughts? Opinions?

Todd Snider

Compiler Group
Texas Instruments Incorporated
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190214/fb20907a/attachment.html>

via llvm-dev

2019-Feb-14 18:05 UTC

head link

[llvm-dev] [RFC] Potential extension to asm statement functionality

hi Todd,

I am no expert in the area of asm statements, and they are not a clang-specific
extension AFAIK, so whatever syntactic and semantic changes might be necessary
ought to be specified in conjunction with the other compiler projects that
support the feature.

I am not the right person to pursue this; mainly I wanted to call out that this
kind of request has come up multiple times and so we should do something about
it.

--paulr

From: Snider, Todd [mailto:t-snider at ti.com]
Sent: Thursday, February 14, 2019 12:53 PM
To: Robinson, Paul; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] [RFC] Potential extension to asm statement functionality


Hi Paul,

Regarding the "No Touchie!" constraint idea for asm statements: would
this be a new qualifier (like volatile) that could be applied to the asm
statement?
Since the constraint is not necessarily associated with an input or output
operand, it seems that introducing the constraint via the qualifier field might
work.

All,

The volatile qualifier on an asm statement already indicates that the statement
should be assumed to have side effects.
Could we extend the functionality of volatile to also mean the asm statement is
not duplicable?

~ Todd

From: Snider, Todd
Sent: Wednesday, February 13, 2019 11:40 AM
To: 'paul.robinson at sony.com'; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] [RFC] Potential extension to asm statement functionality


The proposed "lbl" constraint below:
   __asm __volatile__ ("\t.global\t%0\n%0:\n" : "lbl"
(my_hook_fcn));

is not quite a "No Touchie!" constraint, but it does allow the user to
set the isNotDuplicable flag on the INLINEASM that comes out of the asm
statement in order to circumvent optimizations like Tail Duplication.  But
setting the isNotDuplicable flag is not really enough. If the function that
contains the "lbl" constrained asm statement is inlined into a
function in the same compilation unit, the compiler will error out with a symbol
redefinition error.

We may need something on the level of a "No Touchie!" constraint.

Perhaps a new builtin function that resolves to a global label definition is a
better alternative for this use case?

~ Todd

From: paul.robinson at sony.com [mailto:paul.robinson at sony.com]
Sent: Tuesday, February 12, 2019 2:32 PM
To: Snider, Todd; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

This tactic has been tried before, I'm pretty sure.  It's an attempt to
do simple instrumentation without having to hack the compiler itself (you do
some manual coding or preprocessing, and poof you get useful info in your object
file).  But our compiler is too clever.

Some sort of "No Touchee!" constraint would help this use-case a lot.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, February 12, 2019 3:06 PM
To: Eli Friedman; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Potential extension to asm statement functionality


The team I am working with is using asm statements containing label definitions
as a way of instrumentation so that when an application is loaded into their
debug and test framework, the labels will cause breakpoints to be set at
strategic points where they can query the state of the processor that the
application is running on.

~ Todd

From: Eli Friedman [mailto:efriedma at quicinc.com]
Sent: Tuesday, February 12, 2019 1:36 PM
To: Snider, Todd; llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

Can you go into a bit more detail about why someone would want to do this, as
opposed to just writing a file scope inline asm, or a separate file in assembly?
I can't think of any practical use for the fact that the label is
"inside" the function body.

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, February 12, 2019 10:18 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] [RFC] Potential extension to asm statement
functionality


Suppose a programmer wants to inject their own global label definition into the
body of a function with some guarantee that it will not be removed by the
compiler.

One way to do this is to define a global label with an asm statement knowing
that the asm statement will not be invoked until after the compiler's
optimization passes have run, but the following case demonstrates that a label
defined with an asm statement is still susceptible to being duplicated:

#include <stdint.h>
uint32_t f(uint32_t x);
uint32_t g(uint32_t x);

uint32_t f(uint32_t x) {
    uint32_t returnValue = g(x);

    if (returnValue > 0U) {
        returnValue = 0x40000000;
    }
    else {
        returnValue = 0x80000000;
    }
    __asm __volatile__ ("\t.global my_hook_fcn\nmy_hook_fcn:\n");
    return returnValue;
}

uint32_t g(uint32_t x) {
    return x >> 1U;
}

If the above definition of f() is compiled with optimization at level 1 or
higher, the TailDuplication optimization pass will duplicate and move the asm
statement and return up into the if block and the else block before the asm
statement is invoked. When the now duplicate asm statements are later invoked,
the compiler will detect a symbol redefinition error.

To address this situation, the asm statement functionality could be extended to
comprehend whether it contains a label definition, and if it does, to disallow
duplication of the asm statement.

There are a couple of different approaches that could be taken to implement
this:

  1.  Parse the content of the assembly string argument to the asm statement in
the compiler front-end (during EmitAsmStmt(), for example) to determine if it
contains a label definition, and if it does set the isNotDuplicable flag on the
INLINEASM record that is created to represent the asm statement in the IR. To
date, there is no precedence for processing the content of the assembly string
argument until the asm statement is invoked before the integrated  assembler
starts processing the generated machine code.
  2.  Add a label constraint to the input and output operand syntax for asm
statements. i.e.
__asm __volatile__ ("\t.global\t%0\n%0:\n" : "lbl"
(my_hook_fcn));
The "lbl" constraint would tell the compiler to mark the asm statement
as isNotDuplicable when an INLINEASM record is created to represent it

There are alternatives to using an asm statement for this purpose, but I
wondered if such an extension would be useful/valuable to the wider community.

Thoughts? Opinions?

Todd Snider

Compiler Group
Texas Instruments Incorporated
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190214/7a34a9d0/attachment.html>

Snider, Todd via llvm-dev

2019-Feb-14 20:30 UTC

head link

[llvm-dev] [RFC] Potential extension to asm statement functionality

Thanks Paul.

Another possible way to help an asm statement inhibit particular optimizations
is to extend the list of recognized special clobber arguments, for example:

   __asm __volatile__("\t.global\tuserlabel\nuserlabel:\n" : : :
"label");

Might be used to inform the compiler that the asm statement contains a label
definition and is therefore not duplicable.

A programmer would still need to apply a noinline attribute to a function that
contains such an asm statement.

Any thoughts about this?

~ Todd

From: paul.robinson at sony.com [mailto:paul.robinson at sony.com]
Sent: Thursday, February 14, 2019 12:06 PM
To: Snider, Todd; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

hi Todd,

I am no expert in the area of asm statements, and they are not a clang-specific
extension AFAIK, so whatever syntactic and semantic changes might be necessary
ought to be specified in conjunction with the other compiler projects that
support the feature.

I am not the right person to pursue this; mainly I wanted to call out that this
kind of request has come up multiple times and so we should do something about
it.

--paulr

From: Snider, Todd [mailto:t-snider at ti.com]
Sent: Thursday, February 14, 2019 12:53 PM
To: Robinson, Paul; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] [RFC] Potential extension to asm statement functionality


Hi Paul,

Regarding the "No Touchie!" constraint idea for asm statements: would
this be a new qualifier (like volatile) that could be applied to the asm
statement?
Since the constraint is not necessarily associated with an input or output
operand, it seems that introducing the constraint via the qualifier field might
work.

All,

The volatile qualifier on an asm statement already indicates that the statement
should be assumed to have side effects.
Could we extend the functionality of volatile to also mean the asm statement is
not duplicable?

~ Todd

From: Snider, Todd
Sent: Wednesday, February 13, 2019 11:40 AM
To: 'paul.robinson at sony.com'; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] [RFC] Potential extension to asm statement functionality


The proposed "lbl" constraint below:
   __asm __volatile__ ("\t.global\t%0\n%0:\n" : "lbl"
(my_hook_fcn));

is not quite a "No Touchie!" constraint, but it does allow the user to
set the isNotDuplicable flag on the INLINEASM that comes out of the asm
statement in order to circumvent optimizations like Tail Duplication.  But
setting the isNotDuplicable flag is not really enough. If the function that
contains the "lbl" constrained asm statement is inlined into a
function in the same compilation unit, the compiler will error out with a symbol
redefinition error.

We may need something on the level of a "No Touchie!" constraint.

Perhaps a new builtin function that resolves to a global label definition is a
better alternative for this use case?

~ Todd

From: paul.robinson at sony.com [mailto:paul.robinson at sony.com]
Sent: Tuesday, February 12, 2019 2:32 PM
To: Snider, Todd; efriedma at quicinc.com
Cc: llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

This tactic has been tried before, I'm pretty sure.  It's an attempt to
do simple instrumentation without having to hack the compiler itself (you do
some manual coding or preprocessing, and poof you get useful info in your object
file).  But our compiler is too clever.

Some sort of "No Touchee!" constraint would help this use-case a lot.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, February 12, 2019 3:06 PM
To: Eli Friedman; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Potential extension to asm statement functionality


The team I am working with is using asm statements containing label definitions
as a way of instrumentation so that when an application is loaded into their
debug and test framework, the labels will cause breakpoints to be set at
strategic points where they can query the state of the processor that the
application is running on.

~ Todd

From: Eli Friedman [mailto:efriedma at quicinc.com]
Sent: Tuesday, February 12, 2019 1:36 PM
To: Snider, Todd; llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm statement
functionality

Can you go into a bit more detail about why someone would want to do this, as
opposed to just writing a file scope inline asm, or a separate file in assembly?
I can't think of any practical use for the fact that the label is
"inside" the function body.

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Snider,
Todd via llvm-dev
Sent: Tuesday, February 12, 2019 10:18 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] [RFC] Potential extension to asm statement
functionality


Suppose a programmer wants to inject their own global label definition into the
body of a function with some guarantee that it will not be removed by the
compiler.

One way to do this is to define a global label with an asm statement knowing
that the asm statement will not be invoked until after the compiler's
optimization passes have run, but the following case demonstrates that a label
defined with an asm statement is still susceptible to being duplicated:

#include <stdint.h>
uint32_t f(uint32_t x);
uint32_t g(uint32_t x);

uint32_t f(uint32_t x) {
    uint32_t returnValue = g(x);

    if (returnValue > 0U) {
        returnValue = 0x40000000;
    }
    else {
        returnValue = 0x80000000;
    }
    __asm __volatile__ ("\t.global my_hook_fcn\nmy_hook_fcn:\n");
    return returnValue;
}

uint32_t g(uint32_t x) {
    return x >> 1U;
}

If the above definition of f() is compiled with optimization at level 1 or
higher, the TailDuplication optimization pass will duplicate and move the asm
statement and return up into the if block and the else block before the asm
statement is invoked. When the now duplicate asm statements are later invoked,
the compiler will detect a symbol redefinition error.

To address this situation, the asm statement functionality could be extended to
comprehend whether it contains a label definition, and if it does, to disallow
duplication of the asm statement.

There are a couple of different approaches that could be taken to implement
this:

  1.  Parse the content of the assembly string argument to the asm statement in
the compiler front-end (during EmitAsmStmt(), for example) to determine if it
contains a label definition, and if it does set the isNotDuplicable flag on the
INLINEASM record that is created to represent the asm statement in the IR. To
date, there is no precedence for processing the content of the assembly string
argument until the asm statement is invoked before the integrated  assembler
starts processing the generated machine code.
  2.  Add a label constraint to the input and output operand syntax for asm
statements. i.e.
__asm __volatile__ ("\t.global\t%0\n%0:\n" : "lbl"
(my_hook_fcn));
The "lbl" constraint would tell the compiler to mark the asm statement
as isNotDuplicable when an INLINEASM record is created to represent it

There are alternatives to using an asm statement for this purpose, but I
wondered if such an extension would be useful/valuable to the wider community.

Thoughts? Opinions?

Todd Snider

Compiler Group
Texas Instruments Incorporated
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190214/351d6e83/attachment.html>

James Y Knight via llvm-dev

2019-Feb-14 20:37 UTC

head link

[llvm-dev] [RFC] Potential extension to asm statement functionality

There's a related problem. Possibly we can solve both at the same time.

There is currently a gaping hole in the IR-level semantics for module-level
asm statements. Those global asm statements are quite commonly used to
define global symbols. However, the set of symbols defined by an object
file is quite important for the compiler to know and reason about, even
before the assembler has run. This is true *especially* when we're doing
linking before assembling (as with LTO).

We do not currently have any way to annotate what symbols a global
module-level asm defines.

We currently hack around things by essentially running the assembler
backend in order to list the symbols defined by IR. Which is a _super-ugly_
layering violation and leads to the ridiculous situation where
"llvm-ar"
including all the assembler backends.

To (eventually) fix this, I think it should be somehow required at the IR
level to declare the names of all symbols defined by an asm statement.

But, if we do that at the IR level, what do we then do in clang to populate
it, since the C-level syntax doesn't have that? Well, it'd be great if
we
could add C-level syntax to specify it. But, I'm not sure we can reasonably
add that, and even if we can, it'd be an eternity  before it could be
_required_. So, then, that just means clang instead needs to be the one
scanning the asm to find symbol definitions, in order to generate the
proper IR. While still ugly, that seems like a better situation than what
we have now.



On Thu, Feb 14, 2019 at 1:06 PM via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> hi Todd,
>
>
>
> I am no expert in the area of asm statements, and they are not a
> clang-specific extension AFAIK, so whatever syntactic and semantic changes
> might be necessary ought to be specified in conjunction with the other
> compiler projects that support the feature.
>
>
>
> I am not the right person to pursue this; mainly I wanted to call out that
> this kind of request has come up multiple times and so we should do
> something about it.
>
>
>
> --paulr
>
>
>
> *From:* Snider, Todd [mailto:t-snider at ti.com]
> *Sent:* Thursday, February 14, 2019 12:53 PM
> *To:* Robinson, Paul; efriedma at quicinc.com
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* RE: [llvm-dev] [RFC] Potential extension to asm statement
> functionality
>
>
>
>
>
> Hi Paul,
>
>
>
> Regarding the “No Touchie!” constraint idea for asm statements: would this
> be a new qualifier (like volatile) that could be applied to the asm
> statement?
>
> Since the constraint is not necessarily associated with an input or output
> operand, it seems that introducing the constraint via the qualifier field
> might work.
>
>
>
> All,
>
>
>
> The volatile qualifier on an asm statement already indicates that the
> statement should be assumed to have side effects.
>
> Could we extend the functionality of volatile to also mean the asm
> statement is not duplicable?
>
>
>
> ~ Todd
>
>
>
> *From:* Snider, Todd
> *Sent:* Wednesday, February 13, 2019 11:40 AM
> *To:* 'paul.robinson at sony.com'; efriedma at quicinc.com
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* RE: [llvm-dev] [RFC] Potential extension to asm statement
> functionality
>
>
>
>
>
> The proposed “lbl” constraint below:
>
>    __asm __volatile__ (“\t.global\t%0\n%0:\n” : “lbl” (my_hook_fcn));
>
>
>
> is not quite a “No Touchie!” constraint, but it does allow the user to set
> the isNotDuplicable flag on the INLINEASM that comes out of the asm
> statement in order to circumvent optimizations like Tail Duplication.  But
> setting the isNotDuplicable flag is not really enough. If the function that
> contains the “lbl” constrained asm statement is inlined into a function in
> the same compilation unit, the compiler will error out with a symbol
> redefinition error.
>
>
>
> We may need something on the level of a “No Touchie!” constraint.
>
>
>
> Perhaps a new builtin function that resolves to a global label definition
> is a better alternative for this use case?
>
>
>
> ~ Todd
>
>
>
> *From:* paul.robinson at sony.com [mailto:paul.robinson at sony.com]
> *Sent:* Tuesday, February 12, 2019 2:32 PM
> *To:* Snider, Todd; efriedma at quicinc.com
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm
> statement functionality
>
>
>
> This tactic has been tried before, I'm pretty sure.  It's an
attempt to do
> simple instrumentation without having to hack the compiler itself (you do
> some manual coding or preprocessing, and poof you get useful info in your
> object file).  But our compiler is too clever.
>
>
>
> Some sort of "No Touchee!" constraint would help this use-case a
lot.
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of
*Snider,
> Todd via llvm-dev
> *Sent:* Tuesday, February 12, 2019 3:06 PM
> *To:* Eli Friedman; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] [RFC] Potential extension to asm statement
> functionality
>
>
>
>
>
> The team I am working with is using asm statements containing label
> definitions as a way of instrumentation so that when an application is
> loaded into their debug and test framework, the labels will cause
> breakpoints to be set at strategic points where they can query the state of
> the processor that the application is running on.
>
>
>
> ~ Todd
>
>
>
> *From:* Eli Friedman [mailto:efriedma at quicinc.com]
> *Sent:* Tuesday, February 12, 2019 1:36 PM
> *To:* Snider, Todd; llvm-dev at lists.llvm.org
> *Subject:* [EXTERNAL] RE: [llvm-dev] [RFC] Potential extension to asm
> statement functionality
>
>
>
> Can you go into a bit more detail about why someone would want to do this,
> as opposed to just writing a file scope inline asm, or a separate file in
> assembly?  I can’t think of any practical use for the fact that the label
> is “inside” the function body.
>
>
>
> -Eli
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Snider,
> Todd via llvm-dev
> *Sent:* Tuesday, February 12, 2019 10:18 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [EXT] [llvm-dev] [RFC] Potential extension to asm statement
> functionality
>
>
>
>
>
> Suppose a programmer wants to inject their own global label definition
> into the body of a function with some guarantee that it will not be removed
> by the compiler.
>
>
>
> One way to do this is to define a global label with an asm statement
> knowing that the asm statement will not be invoked until after the
> compiler’s optimization passes have run, but the following case
> demonstrates that a label defined with an asm statement is still
> susceptible to being duplicated:
>
>
>
> #include <stdint.h>
>
> uint32_t f(uint32_t x);
>
> uint32_t g(uint32_t x);
>
>
>
> uint32_t f(uint32_t x) {
>
>     uint32_t returnValue = g(x);
>
>
>
>     if (returnValue > 0U) {
>
>         returnValue = 0x40000000;
>
>     }
>
>     else {
>
>         returnValue = 0x80000000;
>
>     }
>
>     __asm __volatile__ ("\t.global my_hook_fcn\nmy_hook_fcn:\n");
>
>     return returnValue;
>
> }
>
>
>
> uint32_t g(uint32_t x) {
>
>     return x >> 1U;
>
> }
>
>
>
> If the above definition of f() is compiled with optimization at level 1 or
> higher, the TailDuplication optimization pass will duplicate and move the
> asm statement and return up into the if block and the else block before the
> asm statement is invoked. When the now duplicate asm statements are later
> invoked, the compiler will detect a symbol redefinition error.
>
>
>
> To address this situation, the asm statement functionality could be
> extended to comprehend whether it contains a label definition, and if it
> does, to disallow duplication of the asm statement.
>
>
>
> There are a couple of different approaches that could be taken to
> implement this:
>
>    1. Parse the content of the assembly string argument to the asm
>    statement in the compiler front-end (during EmitAsmStmt(), for example)
to
>    determine if it contains a label definition, and if it does set the
>    isNotDuplicable flag on the INLINEASM record that is created to
represent
>    the asm statement in the IR. To date, there is no precedence for
processing
>    the content of the assembly string argument until the asm statement is
>    invoked before the integrated  assembler starts processing the generated
>    machine code.
>    2. Add a label constraint to the input and output operand syntax for
>    asm statements. i.e.
>
> __asm __volatile__ (“\t.global\t%0\n%0:\n” : “lbl” (my_hook_fcn));
>
> The “lbl” constraint would tell the compiler to mark the asm statement as
> isNotDuplicable when an INLINEASM record is created to represent it
>
>
>
> There are alternatives to using an asm statement for this purpose, but I
> wondered if such an extension would be useful/valuable to the wider
> community.
>
>
>
> Thoughts? Opinions?
>
>
>
> Todd Snider
>
>
>
> Compiler Group
>
> Texas Instruments Incorporated
> _______________________________________________
> 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/20190214/41024a5e/attachment.html>

llvm dev - Feb 2019 - [RFC] Potential extension to asm statement functionality

[llvm-dev] [RFC] Potential extension to asm statement functionality

[llvm-dev] [RFC] Potential extension to asm statement functionality

[llvm-dev] [RFC] Potential extension to asm statement functionality

[llvm-dev] [RFC] Potential extension to asm statement functionality