similar to: [LLVMdev] LeafBlock from NodeBlock

hi Ryan, Any example? best regards ether On Wed, Apr 4, 2012 at 9:27 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Is there a way (without writing a pass to manually copy the block, etc) to > eliminate this type of CFG creation? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu

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 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:

+ 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:

I am trying to employ the ABCD optimization pass to remove unnecessary branches in the code my compiler generates. But in its current form (yesterday's trunk) the pass changes the behavior of the code such that execution yields invalid results, which is obviously not what I want. The switch in the following listing is used to implement a virtual method call, 99999 and 100000 are type

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, > >

Thanks a lot. On Mon, Sep 12, 2016 at 1:42 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > If you use the default header file under clang/lib/Headers/opencl-c.h, > get_global_id will be mangled. > > > > If you want to declare get_global_id in your own header, add > __attribute__((overloadable)), then it will be mangled. > > > > Sam > > > >

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

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

Hi Hal, I add a function named "vectorizeBasicBlock" which allow users to perform basic block vectoirzation inside their pass. But i am not sure whether i missed something as no one use the function right now (But it will be used by Polly sometimes later[1]). In addition, we (tobi and me) also want to make the vectorizer being configured command line flags. To achieve this, we are

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:

> 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

> > 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

Hi mailing list, I has been working on a large project that is based on LLVM 3.1. Recently we are thinking to introduce an LLVM bc converter from LLVM 3.9 to LLVM 3.1, such that we can introduce some of the newest LLVM analyses and optimizations to our LLVM 3.1 based project. Have you worked on similar things that converting LLVM bc downward and has anything to share? Thanks Hongbin

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

Thanks, Looks like inst combine do the job On Tue, Apr 25, 2017 at 9:36 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Apr 25, 2017 at 9:24 PM, Hongbin Zheng via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > > > > Is there a pass in LLVM that can optimize: > > > > if (x) > > a[i] = y0; > > else > >

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

Hi Eugene, It is strange, I also do a clean build with CMake+make with r301734 and it is ok. Could you provide more details? Thanks Hongbin On Mon, May 1, 2017 at 10:58 AM, Eugene Zelenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, Michael! > > On Sun, Apr 30, 2017 at 2:06 PM, Michael Kruse <llvmdev at meinersbur.de> > wrote: > > 2017-04-29 0:49

2017-05-01 20:16 GMT+02:00 Eugene Zelenko via llvm-dev <llvm-dev at lists.llvm.org>: > Hi, Hongbin! > > On Mon, May 1, 2017 at 11:06 AM, Hongbin Zheng <etherzhhb at gmail.com> wrote: >> Hi Eugene, >> >> It is strange, I also do a clean build with CMake+make with r301734 and it >> is ok. Could you provide more details? >> >> Thanks >>

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)