similar to: Target hardware loop instruction via intrinsics

I'm working on getting an out of tree target machine verifier clean. This has found some nasty bugs so I'd like to continue with it. One instance of bad machine code is "Using an undefined physical register". This arises whenever undef propagates to a machine instruction. Usually this means the input was meaningless - e.g. call an undefined address. Other times it's a

Hello. I come back to this thread. But I want to ask a slightly different question. Is there a way to have LLVM IR language intrinsics that are given at construction time a string that is written at assembly generation time as it is? (so, basically having placeholders of strings in LLVM that remain untouched until the end, including code generation time.) More exactly, I would

On 5/30/2017 11:00 AM, Quentin Colombet via llvm-dev wrote: > The way I was seeing this happening is by changing incrementally the > parser of the MIR format. Basically, I’d like the parser to get smarter > and smarter to a point where it could understand assembly mnemonics and > build the MachineFunction. The rest of the infrastructure would stay the > same. I'm not sure

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

Il 25/07/2012 10:07, Eli Friedman ha scritto: > On Wed, Jul 25, 2012 at 12:48 AM, Michele Scandale > <michele.scandale at gmail.com> wrote: >> 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

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

Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be

Hi everyone, we've been prototyping an optimizing assembler for Hexagon for the purpose of updating legacy assembly for new architectures, packet rules, and instruction latencies. It seems like others would be interested in using this and we're looking for any related feedback: has it been attempted before, who's interested, or any general suggestions. We're using the

On Wed, Jul 25, 2012 at 12:48 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > 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

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

On 05/26/2017 03:02 PM, Matthias Braun wrote: > >> Regarding SDAG, and given that poison is already there, we would need >> to adopt a similar solution to the IR. Maybe right now we can get >> away with it because nsw is not exploited significantly (as you say). >> Just because there’s no explicit poison in SDAG, just having nsw is >> sufficient to cause

The comment in test/CodeGen/X86/branchfolding-undef.mir states that such merging is legal, however doing so can actually generate wrong code: Consider this (valid code): --- name: fred tracksRegLiveness: true body: | bb.0: successors: %bb.1, %bb.2 J2_jumpt undef %p0, %bb.2, implicit-def %pc J2_jump %bb.1, implicit-def %pc bb.1: successors: %bb.3 %r0 =

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 [

Hi Eric, > On Nov 19, 2015, at 12:46 PM, Eric Christopher <echristo at gmail.com> wrote: > > Hi Quentin, > > > *** Goals *** > > The high level goals of the new instruction selector are: > - Global instruction selector. > - Fast instruction selector. > > Are these separate or the same? It reads like two instruction selectors at the moment. They are

Yes, immediately after branch folding the code would still behave the same as the original. At the same time, any subsequent optimization may "exploit" the incorrect liveness information to do something bad. If you add -run-pass if-converter, you'll get: # After If Converter # Machine code for function fred: IsSSA, NoPHIs, TracksLiveness, NoVRegs BB#0: %R0<def>

When I run lighttpd 1.4.10 [on Mac OS X] the socket file is called ''fcgi.socket-'', versus ''fcgi.socket-0'' that I get under 1.4.8. Further, when the FCGI daemon quits, the file does not get deleted, and I cannot restart my Rails app until I manually remove it. Can anyone confirm before I raise a bug at lighttpd.net?

Dear lots of people, The first comments on the 3.7 release expressed surprise that there were no changes to the X86 or ARM targets. There had of course been a lot of hard work and many changes, but none of it was mentioned in the release notes. Please help make the release notes more comprehensive this time. The notes are of course not as important as the actual code, but they do get read, and

> 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

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 instructions > > Hello.