similar to: Alignment of the StoreInst

Hi Hongbin, On 16 December 2016 at 11:57, Hongbin Zheng via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We have an "align 4" in the StoreInst. Does this mean > 1) the address 'A' should be aligned to 4 bytes? > 2) the lower 2 bits of 'A' should be always 0? Yes, these are both the same. It means the compiler will assume those facts when reasoning about

Hi Tim, Thanks for the explanation. The above code snippets is actually extracted by bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. I get a different result if I cast the pointer to int and mask away the lower two bits and cast the int back to pointer. While casting pointer to int and back to pointer do not cause any problem. Thanks Hongbin On Fri, Dec 16, 2016 at

Hi Hongbin, On 16 December 2016 at 12:22, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Thanks for the explanation. The above code snippets is actually extracted by > bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. > I get a different result if I cast the pointer to int and mask away the > lower two bits and cast the int back to pointer. While

Hi Mats, When the struct is packed, explicit byte array is introduced to pad the struct. (I saw this happened in clang 3.9.) I want to check if a byte or byte array in an LLVM struct is introduce for explicit padding or not. I don't need to worry about this problem in case the newest clang do not introduce byte array anymore. Thanks Hongbin On Thu, May 18, 2017 at 1:03 AM, mats petersson

Hi, I had cloned zorg from https://llvm.org/svn/llvm-project/zorg/trunk, then I try to start the buildbot master located in buildbot/osuosl/master (the absolute path is /nfs/home/hongbin.zheng/buildbot/zorg/buildbot/osuosl/master) by simply typing "buildbot start" And I get something like this from my twistd.log: --- <exception caught here> --- File

Hongbin, Did you tweak sys.path? # Extend paths to allow loading zorg and config modules. import os, sys path = os.path.join(os.environ.get('HOME'), 'zorg', 'buildbot', 'osuosl', 'master') if path not in sys.path: sys.path.append(path) path = os.path.join(os.environ.get('HOME'), 'zorg') if path not in sys.path: sys.path.append(path)

the packed + aligned attribute will automatically introduce explicit padding byte array: https://godbolt.org/g/TlHX2g Sometimes Clang will decide to automatically pack the struct/class in C++, I don't know the details here, but looks like it is related to inheritance. Thanks Hongbin On Thu, May 18, 2017 at 1:32 AM, mats petersson <mats at planetcatfish.com> wrote: > How do you

I don't see any problem mangling it to be honest even though there seems to be only one prototype anyways. We could add restrict in as well. Cheers, Anastasia ________________________________ From: Hongbin Zheng <etherzhhb at gmail.com> Sent: 17 September 2016 05:32:54 To: Liu, Yaxun (Sam) Cc: cfe-dev at lists.llvm.org; llvm-dev; Bader, Alexey (alexey.bader at intel.com); Anastasia

Hi, Yes, I can see why that would not work. The sinking algorithm in SimplifyCFG isn't particularly clever. In particular it can't reason about memory ordering and aliasing. In unswitch1(), it can identify that the stores correlate because the correlating stores appear in the same relative source order. In unswitch2() they have been permuted, and the algorithm cannot deal with this. This

Hi Daniel, Thanks a lot for all these explanation, I will try it out. Hongbin On Tue, Apr 25, 2017 at 7:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Apr 25, 2017 at 6:42 PM, Hongbin Zheng <etherzhhb at gmail.com> > wrote: > >> >> >> On Tue, Apr 25, 2017 at 6:32 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote:

> > I also have a look at the code, looks like it directly parse the bitcode > and build in memory representation in a different LLVM version than the > bitcode. Is this correct? According to your description, I guess the BitCodeWriter should be the one > to do the bitcode version downgrade, right? I think so. I don't know much about it and don't want to give you

Like I said, i'm nearly positive there is a much faster way, as the sets are mostly shared except in the cyclic case, and in all reducible cyclic cases, removal of back-arcs does not affect dominance (because in any reducible flowgraph, v dominates u whenever u,v is a back-arc) On Tue, Apr 25, 2017 at 7:38 PM, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Daniel, > >

+ Alexey Anastasia According to SPIR spec v1.2 s2.10.3 2.10.3 The printf function The printf function is supported, and is mangled according to its prototype as follows: int printf(constant char * restrict fmt, ... ) Note that the ellipsis formal argument (...) is mangled to argument type specifier z It seems printf should be mangled. Alexey/Anastasia, What do you think? Thanks. Sam From:

Hi Steve, Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the oldest version of bitcode that the TOT bitcode reader supports? Also, why do you generate bitcode instead of the textural representation, i.e. the "ll" file, for older version of LLVM? I guess generating "ll" code is simpler. Another approach I am

On Wed, Mar 29, 2017 at 2:15 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/29/2017 1:05 PM, Hongbin Zheng wrote: > >> Hi Eli, >> >> Thanks. Do you mean ideally we should extend SimplifyIndVar to do the >> sdiv->udiv replacement? >> > > I haven't really looked into it closely, but it seems to make sense. Ok. Once I extend

> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Hongbin, > > On Tue, Aug 2, 2016 at 8:26 PM, Hongbin Zheng <etherzhhb at gmail.com <mailto:etherzhhb at gmail.com>> wrote: > Hi Steve, > > Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the

On Tue, Apr 25, 2017 at 6:32 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Apr 25, 2017 at 6:17 PM, Hongbin Zheng <etherzhhb at gmail.com> > wrote: > >> Hi Daniel, >> >> I mean "*As a set*, B + C dominate D". >> >> On Tue, Apr 25, 2017 at 5:42 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote:

Thanks Steve and Mehdi for the explanation. Steve, I am a little be confused by looking at the code in https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp. Looks like the BitcodeReader do some translation while reading the bitcode. If LLVM ToT can read the bitcode of LLVM 3.0, while can't we just use the bitcode reader in LLVM

On 11/17/2017 02:01 AM, Hongbin Zheng wrote: > Do you mean a and b are noalias if: > > static int foo(int *a, int *b) { > return a[0] + b[0]; > } > > int bar(int *x) { > return foo(x+1, x); > } > > ? > > To me, because "AA.alias((x+1, MemoryLocation::UnknownSize), > (x, MemoryLocation::UnknownSize)) != NoAlias", so a and b are not noalias.

> On Aug 2, 2016, at 8:49 PM, Stephen Hines <srhines at google.com> wrote: > > > > On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>