similar to: RFC: Generate plain !tbaa tags in place of !tbaa.struct ones

In short, the problem with !tbaa.struct is that in most cases it cannot be converted to !tbaa. For transformations like SROA this means they cannot propagate !tbaa.struct tags for aggregate-accessing instructions like memcpy() calls to the resulting loads and stores. On 31/10/17 05:11, Hal Finkel wrote: > > On 10/18/2017 05:49 AM, Ivan Kosarev via llvm-dev wrote: >> Hello,

To clarify further, what this paper proposes is to use !tbaa for all kinds of accesses, including aggregate ones, so we don't need to bother trying to convert them when an aggregate access becomes a series of scalar accesses or vice versa. As I said, in most cases such conversions are not possible anyway, because !tbaa.struct tags do not refer to the type of the aggregate itself and only

On 02/11/17 05:54, Hal Finkel wrote: > > On 10/31/2017 05:02 AM, Ivan Kosarev wrote: >> To clarify further, what this paper proposes is to use !tbaa for all >> kinds of accesses, including aggregate ones, so we don't need to >> bother trying to convert them when an aggregate access becomes a >> series of scalar accesses or vice versa. As I said, in most cases

I'm interested in what we can do about TBAA for loads that the compiler inserts when optimizing loads into smaller loads (e.g. what SROA does). I'm gonna set the stage by using a small C snippet, because I think C has the best-understood implementation of TBAA among the folks on the list. However, I was unable to actually come up with an example where this inhibits optimizations coming

On Sun, Aug 20, 2017 at 2:47 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > >>>> the type of (*x) is not compatible with the type of (*b) or, > >>>> recursively, type of b->i. Similarly, the type of (*b) is > >>>> not compatible with (*x) or, recursively, x->i. > >> ... >

Do you have a formal description of your approach with examples? I have a bit of trouble visualizing exactly what your approach does. On Mon, Aug 14, 2017 at 9:58 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Steven, Hal and Daniel, > > Thanks a lot for your discussion; it really helps with summarizing current > TBAA issues and ways to resolve

Hi Ivan, The code that we have is indeed different from what the 'standard llvm' expects. Let me explain: in our version we came into this situation in two steps: 1) I added support for 'special types' that map directly to types supported by hardware. These types are represented by a struct containing a single iXXX member, providing the necessary bits of the type, and at the

On 08/16/2017 01:59 PM, Ivan A. Kosarev via llvm-dev wrote: > Hal, Daniel, > > Thanks for your responses. Here's a quick formal introduction to the > proposed approach follows. I also attached a couple files to put some > visibility on implementation details. We'd love to hear from you > gentlemen and LLVM community in general on how this fits what you know > about

Hi, I have a question about the current definition of TBAA (See [1]). In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue) For following c-alike code: struct S { int dummy; short e, f; } x,y; struct S* p = &x; int foobar() { x.f=42; *p=y; //**** struct copy return x.f; } We produce:

On Sun, May 14, 2017 at 11:01 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/14/2017 12:49 PM, Daniel Berlin wrote: > > > > On Sun, May 14, 2017 at 10:20 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 05/14/2017 11:06 AM, Daniel Berlin wrote: >> >> >> >> On Sun, May 14, 2017 at 8:37 AM, Hal Finkel <hfinkel at

It's hard to say. What you've described sounds close to a neutral type system implemented in metadata. In particular, ". It also defines a set of language-neutral formal rules that LLVM codegen follows to determine whether a given pair of accesses are allowed to overlap by rules of the input language. " and "the base type followed by field descriptors" etc Despite the

Hi Ivan, thanks for writing it up. This is a pretty long thread, and there are many good points brought up in the heated discussions. Here is my take on many of the points that have been mentioned: 1) The type based aliasing IR annotation should be generic enough to represent aliasing constraints for any frontend languages; 2) The offset based aliasing rules and type based aliasing rule have a

hi, i have a simple code like below, in wich variable "aaa" does not alias to "bbb". i use TBAA to specify this, please see the code. then i ran this code thru LLVM optimization, and i expected that the second "store" instruction is eliminated. however, i am wrong: the second "store" instruction is still there after optimization. perhaps my TBAA setup is

Hi Jun, did you tell "opt" to make use of TBAA? Also, please give complete IR that people can use to reproduce, and instructions on how to reproduce (eg how to run opt). Ciao, Duncan. > i have a simple code like below, in wich variable "aaa" does not alias > to "bbb". > i use TBAA to specify this, please see the code. > > then i ran this code thru

Hi Jun, On 27/09/12 08:02, Jun Koi wrote: > On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: >> Hi Jun, did you tell "opt" to make use of TBAA? Also, please give complete >> IR >> that people can use to reproduce, and instructions on how to reproduce (eg >> how >> to run opt). >> > > actually, i am still

On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, did you tell "opt" to make use of TBAA? Also, please give complete > IR > that people can use to reproduce, and instructions on how to reproduce (eg > how > to run opt). > actually, i am still confused on which options should be given to "opt" for it to use TBAA. any

On Thu, Sep 27, 2012 at 3:31 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jun, > > > On 27/09/12 08:02, Jun Koi wrote: >> >> On Thu, Sep 20, 2012 at 5:18 PM, Duncan Sands <baldrick at free.fr> wrote: >>> >>> Hi Jun, did you tell "opt" to make use of TBAA? Also, please give >>> complete >>> IR >>> that

In https://reviews.llvm.org/D26229 I've proposed dropping support for old style scalar TBAA metadata. Here is the proposed commit message: "We've had support for auto upgrading old style scalar TBAA access metadata into the "new" struct path aware TBAA metadata for 3 years now. The only way to actually generate old style TBAA was explicitly through the IRBuilder API. I

Hi Manman, thanks for the heads up. I looked into what it would take to produce full struct TBAA metadata from the GCC aliasing info (GCC has aliasing info for struct types, in fact for any type), but it looks kind of tricky. The problem is the "offset" field, which doesn't exist in GCC. In GCC the aliasing information forms a DAG, with a node for each type, plus a special root

Hi, I work on DDC, the compiler of a research Haskell dialect, Disciple (disciple.ouroborus.net (http://disciple.ouroborus.net)). We are looking to make use of LLVM's type-based alias analysis metadata to encode non-aliasing information between variables. We have found that the tbaa structure is somewhat limited in its expressivity. In particular we couldn't encode intransitive