similar to: [LLVMdev] Array Region analysis for multithread

What do you mean by test case please ? Using the following commands to compile mcf program can reproduce such issue all the time. Probably it is my version's problem. Because I checked out 3.3version from SVN before published. Could you tell me where Manman modified ? I cannot port to new version very quickly after changing it a lot already. Thanks, - Pengcheng On Nov 5, 2013, at

Hi, What version of clang are you using? I think r174785 is the fix. Manman On Tue, Nov 5, 2013 at 11:04 AM, lipengcheng <pli at cs.rochester.edu> wrote: > What do you mean by test case please ? Using the following commands to > compile mcf program > can reproduce such issue all the time. > > Probably it is my version's problem. Because I checked out 3.3version from

Also r174479. Manman On Tue, Nov 5, 2013 at 11:11 AM, Manman Ren <manman.ren at gmail.com> wrote: > Hi, > > What version of clang are you using? I think r174785 is the fix. > > Manman > > > On Tue, Nov 5, 2013 at 11:04 AM, lipengcheng <pli at cs.rochester.edu> wrote: > >> What do you mean by test case please ? Using the following commands to

Another finding is when I use both -code-model=large and -relocation-model=pic (!!!!!note changed), it still generate the static relocation. So does it mean -relocation-model=pic does not like to work with -code-model=large ? Thanks, -Pengcheng On Nov 6, 2013, at 1:52 PM, lipengcheng <pli at cs.rochester.edu> wrote: > Yep. I tried it. It used a movabsq instruction instead and a

This is from work that Manman did. I thought she'd fixed this particular issue though. Can you file a bug with a test case please? On Nov 5, 2013 10:10 AM, "lipengcheng" <pli at cs.rochester.edu> wrote: > Hello LLVM, > > I encountered the following bugs when I compiled my program in debug > version. > Could someone help me with that ? Really appreciate that.

Hello LLVM, I encountered the following bugs when I compiled my program in debug version. Could someone help me with that ? Really appreciate that. Thanks, Take the mcf program in SPEC2K6 as example. The compiling options are : clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c llvm-link -o mcf.bc obj/mcf.o opt -o mcf.opt.bc mcf.bc -O2 llc -O0 -relocation-model=static -o mcf.s

Yep. I tried it. It used a movabsq instruction instead and a static allocation. Thanks a lot. I will read it immediately. Again thanks. - Pengcheng On Nov 6, 2013, at 1:45 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> If you also give "-code-model=large" then LLVM won't assume that >> "addr" is nearby so it'll use a movabsq with a

Hi, I am new to LLVM and was wondering if there exists a compiler pass that implements array access region analysis (single and/or multithreaded analysis) in the released version. I took a look at: http://llvm.org/docs/Passes.html But I did not see anything directly, although certain passes such as induction variable passes (in which the pass determines that the induction variable used

> If you also give "-code-model=large" then LLVM won't assume that > "addr" is nearby so it'll use a movabsq with a static relocation. Actually, it seems our own Eli has written rather a good description of these code models: http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models/. Well worth the read (the default models he talks about at the

Hi, developers, Recently, I am trying to use the LLVM Region analysis, the LLVM version is 10. I use opt to print out the region analysis result using "opt -view-regions-only region.ll". However, I am confused about the result produced by LLVM, I found that LLVM seems to skip loop preheader when grouping blocks into regions. Here is a simple example code: ```region.c void split(int

Hi , It will be good ,If you get us the sample that assert. Thanks ~Umesh On Tue, Jul 31, 2012 at 11:40 AM, 田中 太郎 <dontforgettobringatowel at live.jp>wrote: > > Hi all, > > I ran across an assertion failure while using region analysis in my passes. > I get the same thing when doing: opt -regions -analyze > > [...] > [1] entry => if.end > End region tree

Hi all, I ran across an assertion failure while using region analysis in my passes. I get the same thing when doing: opt -regions -analyze [...]   [1] entry => if.end End region tree Printing analysis 'Detect single entry single exit regions' for function 'njDecodeSOF': Region tree: [0] entry => <Function Return>   [1] entry => return     [2] if.end => return

On 03/08/2010 11:23 AM, Renato Golin wrote: > On 6 March 2010 02:05, Tobias Grosser<grosser at fim.uni-passau.de> wrote: >> This is useful if you want to restrict an analysis&transformation >> e.g. to side effect free code, code without loops, code without >> irregular control flow, ... > > I'm confused... > > I thought that loop optimization was one

Sent from my iPhone > On Jan 31, 2017, at 7:27 PM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > Remember that, the prepare-phase is invoked in the FE or right after FE, inlining is not happening, that is why we don't call it "pass". Chandler made a good point for this case a long time back. > What I was describing is the inlining in the optimizer

Hello, I'd like to see support in clang/LLVM for multi-core parallelism, especially support for OpenMP. I think that the best way to do this is by designing an LLVM-based API (metadata and intrinsics) for expressing parallelism constructs, and having clang lower OpenMP code to that API. This will allow maximal preservation of optimization capabilities including target-specific lowering. What

We try to use llvm to translate and generate the native code in parallel with multi-thread. But some various bugs will be triggered. We run the following code in multithread environment: ################## BasicBlock::Create(_CTX(), "dispatch", cpu->cur_func, 0); BranchInst::Create(bb_start, label_entry); cpu->exec_engine->getPointerToFunction ##################3 And cpu

On Thu, Jan 19, 2017 at 11:46 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Jan 19, 2017, at 11:36 AM, Adve, Vikram Sadanand via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi Johannes, > > > >> I am especially curious where you get your data from. Tapir [0] (and to > >> some degree PIR [1]) have

On 01/19/2017 03:36 PM, Mehdi Amini via llvm-dev wrote: > >> On Jan 19, 2017, at 1:32 PM, Daniel Berlin <dberlin at dberlin.org >> <mailto:dberlin at dberlin.org>> wrote: >> >> >> >> On Thu, Jan 19, 2017 at 1:12 PM, Mehdi Amini<mehdi.amini at apple.com >> <mailto:mehdi.amini at apple.com>>wrote: >> >> >>>

>>>>Ok, but this looks like a “workaround" for your specific use-case, I don’t see how it can scale as a model-agnostic and general-purpose region semantic. I would say it is a design trade-off. Regardless it is a new instruction or an intrinsics with token/tag, it will consist of model-agnostic part and model-non-agnostic part. The package comes with a framework for parsing

Let me try this. You can simply consider the prepare-phase (e.g. pre-privatization) were done in FE (actually a library can be used by multiple FEs at LLVM IR level), the region is run with 1 thread, region annotation (scope, single-entry-single-exit) as memory barrier conservatively for now (instead of checking individual memory dependency, aliasing via tags which is the actual