similar to: Scaling to many basic blocks

Thanks for your point that out. I just add DataLayout in my code such as "mod->setDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");", still no luck. I'm really confused about this. Do I need to add more passes before -loop-unroll? On Sat, Aug 22, 2015 at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 22, 2015, at 7:27 AM, Xiangyang

On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi, > > Several passes would have troubles with such code (namely, GVN and > JumpThreading). Can you just choose not to run those particular passes? I suppose the big problem would be if there's a problem with the code generation and related stuff like instruction scheduling and

Hello. I am trying to vectorize a CSR SpMV (sparse matrix vector multiplication) procedure but the LLVM loop vectorizer is not able to handle such code. I am using cland and llvm version 3.4 (on Ubuntu 12.10). I use the -fvectorize option with clang and -loop-vectorize with opt-3.4 . The CSR SpMV function is inspired from

> On Aug 19, 2015, at 12:01 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Pete Cooper" <peter_cooper at apple.com>, "Lang Hames" <lhames at gmail.com> >> Cc: "LLVM Developers Mailing

Pete - That patch sounds great! Philip, Hal, Medhi, Gerolf - Thanks very much for the feedback. So how about this: (1) We drop llvm.memcpy's alignment argument and use Pete's alignment-via-metadata patch (whatever version of it passes review). (2) llvm.memcpy retains its current semantics, but we teach clang, SimplifyLibCalls, etc. to add noalias metadata where we know it's safe.

Hi Hal, > If you attach noalias metadata to the memcpy call, it will apply to both the source and destination; we don't have a way to differentiate. It might be true that if you attach both noalias and alias.scope metadata to the call, then querying the call against itself will return NoModRef, but that's really hacky (and, in part, wrong, because the destination still alias with

> On Aug 23, 2015, at 11:35 AM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Sun, Aug 23, 2015 at 01:46:12AM +0100, Russell Wallace via llvm-dev wrote: >> On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <mzolotukhin at apple.com> >> wrote: >> >>> Hi, >>> >>> Several passes would have troubles

Hi Hal > By this I assume you mean some new 'nooverlap' metadata? I don't think we have any existing metadata with the correct semantics. I was thinking we could just use the existing noalias metadata. Implicitly, the current llvm.memcpy semantics are "src and dst overlap perfectly or not at all" (perhaps we should update the docs to reflect this if we plan to rely on

Hi Marcello, Thanks for your reply. I will try to pass down the mask! I have one more question. In my backend I return CSR_RegMask in getCallPreservedMask and return CSR_SaveList in getCalleeSavedRegs. Is that a correct setup? I dumped the regmask and found that callee saved regs are marked 1 and non-callee saved regs are 0. Thanks, Xiaochu On Wed, Aug 26, 2015 at 5:58 PM Marcello Maggioni

On 08/19/2015 09:35 AM, Pete Cooper via llvm-dev wrote: > Hey Lang >> On Aug 18, 2015, at 6:04 PM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi All, >> >> I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. >> >> >> (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy

A mutable interface to object files would be great to have but doesn't exist in any meaningful sense in LLVM today. David's hack and similar tricks are what's necessary right now. I'd love to fix that as its a question that comes up not infrequently. Sent from my iPhone > On Aug 25, 2015, at 2:44 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: >

Dear there, I was wondering how to preserve registers (caller saved) across calls. I implemented getCalleeSavedRegs and getCallPreservedMask. But the non-callee-saved registers are still not saved by caller. I want to spill these registers in use on stack right before the call. From my understanding, the register allocator in llvm will do the spill and restoring automatically? Is there anything I

Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time). Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a

Hi! I have a small issue with the JumpThreading pass (in opt). As described in the code (JumpThreading.cpp), the pass may if certain criteria are fulfilled duplicate the content of a block. If the duplicated block contain a call to @llvm.dbg.declare() you will end up with invalid code as the intrinsic @llvm.dbg.declare() only should occur once for each variable. I think the JumpThreading

Hello, I have code containing conditions and loops. Hence some BB execution are determined at run time depending on condition. Now I want to count only those BB that are always executed irrespective of condition result means reachable. and their execution is evident at compile time. How to do this? Please help Thank You Regards -------------- next part -------------- An HTML attachment was

Hm. I assumed that JumpThreading would be the primary factor in optimizing code like this. Guess not. I'll need to look into SimplifyCFG to see what prevents it from doing the same thing to the other loop: https://godbolt.org/z/F6NjdG On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > I assumed the LLVM-IR behind the godbolt link represented the C code

On Jul 7, 2011, at 10:15 PM, Carlo Alberto Ferraris wrote: > Nella citazione giovedì 7 luglio 2011 19:41:16, John McCall ha scritto: >> On Jul 7, 2011, at 4:33 AM, Carlo Alberto Ferraris wrote: >>> Il 07/07/2011 11:14, Cameron Zwarich ha scritto: >>>> I haven't read the code in detail, but it looks like JumpThreading at least attempts to thread across indirect

Nella citazione giovedì 7 luglio 2011 19:41:16, John McCall ha scritto: > On Jul 7, 2011, at 4:33 AM, Carlo Alberto Ferraris wrote: >> Il 07/07/2011 11:14, Cameron Zwarich ha scritto: >>> I haven't read the code in detail, but it looks like JumpThreading at >>> least attempts to thread across indirect branches. You can either try >>> to fix it or file a

Please see inline. From: Chandler Carruth [mailto:chandlerc at google.com] Sent: Wednesday, August 26, 2015 7:03 PM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Philip Reames <listmail at philipreames.com>; Sanjoy Das <sanjoy at playingwithpointers.com> Subject: Re: [llvm-dev] RFC: alloca -- specify address space for

It seems the problem arises from using multiple reg classes for one MI in the td file, I guess. I'm not sure it takes first available, if I swap the reg classes in the list it does not change and if I replace the GPR reg class with something different than it picks the base reg class fine, potentially it is using the reg class with most available? idk. I just need to create MIs for every