search for: ghostbin

I have IR at https://ghostbin.com/paste/daxv5 <https://ghostbin.com/paste/daxv5> which is meant to exit 1, but it is always exiting 0. I'm using it as a template for checking if two functions @test1 and @test2 are equivalent by checking against the exhaustive possible i16 values. For this particular example it should...

...the IR the divisions are in two separate blocks, and I guess that it must be the reason for the optimisation not taking place. This seems to be proven by using an even loop count like 0xFFFFFFF0 to avoid a middle check. In this case the optimisation works just fine. Here are the IR samples: https://ghostbin.com/paste/r4td2 <https://ghostbin.com/paste/r4td2>. At this point the thoughts arising on my side are: — Should this be considered a bug and reported to llvm-bugs or a desired behaviour? — If this is considered a bug, how is one supposed to fix it? With the exact sample provided the compiler...

...ls it in only one >> BB. >> > Can you add some debug dumping to your pass and give some real-world >> examples of counters that it merges? >> >> I still have the pruned IR from the example I brought up at the start >> of the thread: >> >> https://ghostbin.com/paste/qus2s >> >> Look for the __llvm_prf_alias section. >> > > Could you maybe digest that a bit for us to give source-level examples of > what those counters are that end up aliased? > > Also, in the linked IR there is still a tremendous amount of counter >...

...as a counter > - function bar() is the only caller of foo() and calls it in only one BB. > Can you add some debug dumping to your pass and give some real-world examples of counters that it merges? I still have the pruned IR from the example I brought up at the start of the thread: https://ghostbin.com/paste/qus2s Look for the __llvm_prf_alias section. > The fused counter approach (or the one I suggested which is just a generalization of that (see below)) seems like it can reduce the number of counter updates much more. > > > 4. > > >> The complexity of this pas...

...but we pollute the llvm namespace with "NoAlias" and friends. 4) Use "enum AliasResult { AR_NoAlias = 0, ...}" to get the effect of #2 with some minimal name collision prevention. Thoughts? -Chandler [1] Here is the completely untested sketch of what seems required: https://ghostbin.com/paste/2bso6 On Mon, Jun 15, 2015 at 6:27 PM Daniel Berlin <dberlin at dberlin.org> wrote: > > > > Sad that "alias" is sometimes a noun and sometimes a verb, but if > > it's in the literature, then I guess that's that. > > Yes, you will see both...

Looks like LVI actually does have cases for max and min; would it be better to allow ValueTracking to use range analysis instead? - CL > On Aug 1, 2016, at 8:44 PM, Philip Reames <listmail at philipreames.com> wrote: > >> On 07/29/2016 07:08 PM, Carlos Liam via llvm-dev wrote: >> Hi all, >> >> Say we have this IR: >> >> %1 = icmp slt i16 %x, 0

My understanding is that this checks whether the bit width of the integer *type* fits in the bit width of the mantissa, not the bit width of the integer value. - CL > On Apr 14, 2016, at 6:02 PM, escha at apple.com wrote: > > We already do this to some extent; see this code in InstCombineCasts: > > // fpto{s/u}i({u/s}itofp(X)) --> X or zext(X) or sext(X) or trunc(X) > //

> On 2015-Jun-15, at 16:29, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, Jun 15, 2015 at 3:56 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I like this colour: > > enum class AliasKind /* or AliasCategory? */ { > Null, > Unknown, > Partial, > Complete > }; > > So, the only

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

There have been a lot of responses. I'll try to summarize the thread and respond to some of the questions/feedback. Summary ======= 1. We should teach GlobalDCE to strip out instrumented functions which the inliner cannot delete. 2. Sean suggests adding metadata to loads/stores of counters to convey that they do not alias normal program data. I'm not familiar with AA, but