search for: ppcctrloops

Hello. I'm writing a back end for my research SIMD processor that has an assembly language that is blocked structured, with one-level loops. An example program with my assembly language: REPEAT_X_TIMES(Param2) R0 = LS[offset_A]; END_REPEAT; The LLVM code somewhat equivalent to the above ASM program is: vector.body: %index = phi i64 [

...gt; not enough to preserve the semantics of the code. >> >> Is my approach correct? Does it exist a cleaner and more elegant way to support >> this kind of instruction? I tried to look for a similar instruction in other >> targets, but I've found nothing... > > See PPCCTRLoops.cpp in the PPC backend. > > -Eli > I took a quick look to PPCCTRLoops.cpp, but I don't think it's the same of my case. The instruction I have defines explicitly a GPR register, while the BDNZ defines and uses an implicit dedicated register. I based my optimization pass on what...

..."string_that_llc_codegen_should_output_as_assembly2", [(int_my_intrinsic2)] >; Best regards, Alex On 6/5/2016 5:21 PM, Alex Susu wrote: > Hello. > Hal, the source file you mention (lib/Target/PowerPC/PPCCTRLoops.cpp) makes use of > LLVM IR intrinsics, in this case defined at > [LLVM_repo]/llvm/include/llvm/IR/IntrinsicsPowerPC.td, such as: > // Intrinsics used to generate ctr-based loops. These should only be > // generated by the PowerPC backend! > def int_ppc_mtctr...

Hi Alex, You might find it useful to look at how lib/Target/PowerPC/PPCCTRLoops.cpp works. -Hal ----- Original Message ----- > From: "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, May 30, 2016 5:09:37 PM > Subject: [llvm-dev] Back end with special loop instructio...

I have defined the intrinsic as * def int_loop: Intrinsic<[],[llvm_i8_ty, llvm_empty_ty],[]>;* and also got the Codegen backend support in Instructioninfo.td file. Then created a .ll file to test it. The .ll file is like this *declare void @llvm.loop(i8, label)define void @fn() nounwind readnone {entry: ..... ..... call void @llvm.loop(i8 10, label %entry) ret void}* But

...k, but I think it's > not enough to preserve the semantics of the code. > > Is my approach correct? Does it exist a cleaner and more elegant way to support > this kind of instruction? I tried to look for a similar instruction in other > targets, but I've found nothing... See PPCCTRLoops.cpp in the PPC backend. -Eli

> On that note, I think that in general it would be useful to have some > target-independent (CodeGen) pass that would do the majority of the > work for hardware loop generation. I have thought about it, but I > won't be able to do anything in the short term. > > -Krzysztof > I think a first and useful step would be to let targets optionally have the loop induction

On 3/29/2016 3:05 AM, Jonas Paulsson via llvm-dev wrote: > Could this be done somehow, or is it really so that all targets have to > have their own passes to do this? In the Hexagon backend we also have a separate pass that converts compare+branch loops into hardware loops. We recognize several different patterns of the controlling induction variable, including cases where the increment

Hi Jonas, Are you talking specifically about the induction variable? You might look at what I did for PowerPC's counter-based loops (lib/Target/PowerPC/PPCCTRLoops.cpp, etc.). -Hal ----- Original Message ----- > From: "Jonas Paulsson via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, March 28, 2016 8:02:40 AM > Subject: [llvm-dev] LoopStrengthReduce.cpp >...

Hi, Hexagon has a MIR pass for detecting loops that map onto hardware support. I think a similar approach would be viable for my target but am put off by the complexity of determining whether a given loop is legal to transform. Instead, I would like to pass the responsibility for determining legality onto the C programmer who is assumed sufficiently familiar with the architecture. I think this

Dear all, I'm working on an exploratory backend on llvm. In the instruction set I'm using I have an instruction (called DECJNZ) that decrements a register and, if the decremented value is not zero, jumps (with a relative jump) to a given offset. I've described in tablegen this instruction as follow: def DECJNZ : Instruction { let Namespace = "MyTarget"; let

Hi, I am looking for a way to rewrite induction variables to use an addition of -1 whenever possible (and not otherwise unprofitable). This is needed to utilize hardware loop instructions, which are present on SystemZ (branch on count). Later in the backend, an 'add -1; compare w/ 0; jne 0'-sequence can be replaced with a brct instruction. I could not find any way in the LSR pass to

...R19144: Incorrect offset generated for int-to-fp conversion at -O0 r203054 - The PPC global base register cannot be r0 r199832 - Fix pr18515. r200288 - Handle spilling the PPC GPRC_NOR0 register class r199763 - Fix pointer info on PPC byval stores r202192 - Account for 128-bit integer operations in PPCCTRLoops r198425 - Fix loop rerolling pass failure with non-consant loop lower bound I apologize the delay; I've not had a chance to refine my list until this morning. Thanks again, Hal ----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Tom Stell...

...s). I have some experience, for example, taking optimizations taking advantage of hardware-counter-based loops and moving into the IR level (so that we can take advantage of ScalarEvolution), and it works to some extent, but is also fairly hacky (the legality-checking part of lib/Target/PowerPC/PPCCTRLoops.cpp, for example, needs to understand what legalization will later do - it's the best we can do right now, but it's a mess). If we had better loop analysis at the MI level, this would be much better. We already have some interesting MI-level passes that do interesting things with loops...

...or is it really so that all targets have to have their own passes to do this? /Jonas On 2016-03-29 03:50, Hal Finkel wrote: > Hi Jonas, > > Are you talking specifically about the induction variable? You might look at what I did for PowerPC's counter-based loops (lib/Target/PowerPC/PPCCTRLoops.cpp, etc.). > > -Hal > > ----- Original Message ----- >> From: "Jonas Paulsson via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "llvm-dev" <llvm-dev at lists.llvm.org> >> Sent: Monday, March 28, 2016 8:02:40 AM >> Subject: [llvm...

I've been looking to see if there's a way to get the instruction below (SMAC) emitted from a higher-level construct, but I'm starting to think this is unrealistic. To do so, I'd have to tie-in two other instructions: Firstly, clearing the ASR18 and Y register somewhere near the start of the method, then copying out the value of these registers somewhere near the end of the method,

Regarding the patches, there are two concerns AFAICT: 1. It’s a new instruction and as usual when introducing a new instruction it will require work for some time until most optimizations know about it, and to get rid of any potential perf regression. No big deal; we just need to do the work (and we have already done some of it). 2. The patch was written by a student, which may not have time to

Hi, Arm have recently announced the v8.1-M architecture specification for our next generation microcontrollers. The architecture includes vector extensions (MVE) and support for low-overhead branches (LoB), which can be thought of a style of hardware loop. Hardware loops aren't new to LLVM, other backends (at least Hexagon and PPC that I know of) also include support. These implementations

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an