similar to: [LLVMdev] Inserting a custom switch instruction implementation in backend

Hello Probably the easiest way for you is to lower switch instructions via IR-to-IR pass in the way you want. On Sat, Sep 21, 2013 at 3:43 PM, Marcello Maggioni <marcello at codeplay.com> wrote: > Hi, > > in implementing a backend for a target we work on, I ended up needing to > lower the switch instruction in a very specific way that is quite different > from the standard

----- Original Message ----- > Hello > > Probably the easiest way for you is to lower switch instructions via > IR-to-IR pass in the way you want. In case it helps, lib/Transforms/Utils/LowerSwitch.cpp does generic switch lowering. You might be able to use that as a base for what you need to do. -Hal > > On Sat, Sep 21, 2013 at 3:43 PM, Marcello Maggioni > <marcello

Hello, I'm working on a compiler based on LLVM for a SIMD architecture that supports instruction predication. We would like to implement branching on this architecture using predication. As you know the LLVM-IR doesn't support instruction predication, so I'm not exactly sure on what is the best way to implement it. We came up with some ways to do it in LLVM: - Do not add any

Hi, I'm getting a very strange behaviour while adding already created instructions in batches into basicblocks instead of creating and inserting them immediately. Because I need to insert instructions in a certain specific order inside multiple different BBs I found it easy to use the IRBuilder to create instructions without inserting them into a BB, storing them somewhere (vector, map

We are currently doing something similar to your third option in Hexagon backend. But it is a VLIW so predication is not the only reason for that. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Marcello

Hi Marcello, On Fri, Oct 19, 2012 at 04:38:29PM +0100, Marcello Maggioni wrote: > Hello, > I'm working on a compiler based on LLVM for a SIMD architecture that > supports instruction predication. We would like to implement branching > on this architecture using predication. > As you know the LLVM-IR doesn't support instruction predication, so I'm > not exactly

On Fri, Oct 19, 2012 at 04:38:29PM +0100, Marcello Maggioni wrote: > Hello, > I'm working on a compiler based on LLVM for a SIMD architecture that > supports instruction predication. We would like to implement > branching on this architecture using predication. > As you know the LLVM-IR doesn't support instruction predication, so > I'm not exactly sure on what is the

Hi, while using this function I noticed that Type::getScalarSizeInBits() is not marked as const even if inside its body it just uses only other "const" functions and types. This prevents the usage of the function through const pointers/references to Type without any apparent reason. I propose of marking the function as const. (attached is a patch that does so). Cheers, Marcello --

Hi Marcello, I am sure I've seen some postings on the list concerning architectures that support predicated execution and how to map that to LLVM IR, I'm just not sure anymore when and who was involved :). I have implemented your first suggestion for targets that do not have predicated instructions (where control flow to data flow conversion with explicit maintaining of masks and

Marcello Maggioni <marcello at codeplay.com> writes: > I'm getting a very strange behaviour while adding already created > instructions in batches into basicblocks instead of creating and > inserting them immediately. > > Because I need to insert instructions in a certain specific order > inside multiple different BBs I found it easy to use the IRBuilder to > create

This is the .ll for that graph (attached). I think I understand what you are saying. This particular testcase returns CNC not because the exit block doesn't have a unique predecessor, but because the unique predecessor (the inner loop block) has a successor that is inside the loop (in this case itself, because it's the inner loop block). That doesn't change, anyway, the assuption that

Well, it wasn't intended as a "real" patch to be included , but more as a "proof of concept" for a solution. Do you think it is a valid solution and I'm correct in my assumption? If so then I'll clean up the patch and attach a testcase for inclusion. Thanks! Marcello 2012/2/9 Nick Lewycky <nlewycky at google.com>: > Your patch should include a testcase,

FInally I had the time to complete everything up. Now I included the test case in the patch and the testcase runs with the LLVM tests system. 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is instead a very simple (handmade) test case that triggers the > problem (attached) > Also a more conforming patch has been attached > > 2012/2/9 Marcello Maggioni <hayarms

Probably the issue is solvable in some Codegen prepare pass. That said I still believe some kind of control on if we would like to implement this or not could be useful. Just a question. Why implementing it in SimplifyCFG and not as a separate pass like JumpThreading or something like that? The transformation itself doesn’t seem to fit much in SimplifyCFG. > On 2 Sep 2016, at 13:35, Michael

Attached 2012/2/8 Marcello Maggioni <hayarms at gmail.com>: > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may > be ...) , this one should be ok (and passess all the ScalarEvolution > tests in LLVM): > > diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp > index daf7742..b10fab2 100644 > ---

This is instead a very simple (handmade) test case that triggers the problem (attached) Also a more conforming patch has been attached 2012/2/9 Marcello Maggioni <hayarms at gmail.com>: > This is the .ll for that graph (attached). I think I understand what > you are saying. > This particular testcase returns CNC not because the exit block > doesn't have a unique predecessor,

On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote: > Well, it wasn't intended as a "real" patch to be included , but more > as a "proof of concept" for a solution. Do you think it is a valid > solution and I'm correct in my assumption? If so then I'll clean up > the patch and attach a testcase for inclusion. > I'm

Hi all, I recently created a version of llvm/clang for an architecture with some odd properties: - front end side: -- char,short,int : 20 bits -- long, long long: 40 bits -- pointer: 20 bits On the backend side, I have hardware support for 20-bit registers (and load/stores). (So, I have support for 'i20' and 'i40', but 'i40' is lowered into operations on 'i20')

Hi, LLVMer. I use pseudo-instructions ADJCALLSTACK(DOWN | UP) to adjust call stacks, and it works well with "-O0" option. However, ADJCALLSTACK(DOWN | UP) are removed during codegen DCE pass under "-O2". What have I ignored? Thanks. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML attachment was scrubbed... URL:

You should set them as using/defining your stack register with : let Defs = [STACKREG], Uses = [STACKREG] in { __ YOUR INSTRUCTION __ } Marcello On 04/09/13 07:56, 杨勇勇 wrote: > I use pseudo-instructions ADJCALLSTACK(DOWN | UP) to adjust call > stacks, and it works well with "-O0" option. However, > ADJCALLSTACK(DOWN | UP) are removed during codegen DCE pass under