similar to: [LLVMdev] subcc problem wrt sparc

On 11/12/2009, at 10:43 AM, Anton Korobeynikov wrote: > Hi, Chris > >> That is target independent code, so you should not put sparc specific changes there. It sounds like one of the sparc-specific target hooks is wrong. > Since sparc does not provide any hooks for operation of branches (e.g. > AnalyzeBranch and friends) it might be possible that generic codegen > code is

Hi, There are some generated Sparc assembly code like this: main: ! @main ! BB#0: save %sp, -112, %sp sethi 0, %l0 or %g0, 5, %l1 st %l0, [%fp+-4] st %l1, [%fp+-8] st %l1, [%fp+-12] sethi %hi(.L.str), %l1 ld [%fp+-8], %o1 add %l1, %lo(.L.str), %l1 or %g0, %l1, %o0 call printf nop ld [%fp+-12], %o2 ld [%fp+-8], %l2 sethi %hi(.L.strQ521), %l3 add

On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: > Firstly, the BNE/BA pair should be reduced to a BE (I assume this is > the responsibility of AnalyzeBranch and friends that you mention). Right. Implementing AnalyzeBranch will allow a bunch of block layout and branch optimizations to happen. > However I still wouldn't have expected that to result in the label > being

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is its layout successor, rewrite it to a fallthrough // conditional branch.

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close. However, the PowerPC

Hi, Chris > That is target independent code, so you should not put sparc specific changes there.  It sounds like one of the sparc-specific target hooks is wrong. Since sparc does not provide any hooks for operation of branches (e.g. AnalyzeBranch and friends) it might be possible that generic codegen code is broken in absence of these hooks. -- With best regards, Anton Korobeynikov Faculty

On 02/10/2010 01:31 AM, Nathan Keynes wrote: > On 09/02/2010, at 3:57 AM, Chris Lattner wrote: > > >> On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: >> >>> Firstly, the BNE/BA pair should be reduced to a BE (I assume this is the responsibility of AnalyzeBranch and friends that you mention). >>> >> Right. Implementing AnalyzeBranch

On 09/02/2010, at 3:57 AM, Chris Lattner wrote: > On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: >> Firstly, the BNE/BA pair should be reduced to a BE (I assume this is the responsibility of AnalyzeBranch and friends that you mention). > > Right. Implementing AnalyzeBranch will allow a bunch of block layout and branch optimizations to happen. > >> However I still

According to the docs, InsertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label

On Fri, 26 Jun 2020 at 11:36, Jos? Ab?lio Matos <jamatos at fc.up.pt> wrote: > > On Tuesday, 23 June 2020 16.48.53 WEST Tom Callaway wrote: > > There are a few of those, but not many. > > Hi Tom, > I noticed that for example in R-assertthat you have used the bcond: > > %bcond_with check > > would not it be better to use bootstrap instead to take advantage

Hi Christine, > I am using LLVM 2.8 and llvm-gcc 4.2. Could you please try svn top-of-tree? Clang is also a better choice here. > The assembly files are attached. In the assembly file, the erroneous result > is associated with 'subcc', while the correct ones are associated with 'or'. -- Bruno Cardoso Lopes http://www.brunocardoso.cc

On Fri, 26 Jun 2020 at 12:09, Jos? Ab?lio Matos <jamatos at fc.up.pt> wrote: > > On Friday, 26 June 2020 10.47.13 WEST I?aki Ucar wrote: > > I used bcond locally and wrongly assumed that fedpkg build would > > support --with BCOND and --without BCOND. Instead, the way to activate > > it is to change to "%bcond_with check" and then revert to > >

On Friday, 26 June 2020 10.47.13 WEST I?aki Ucar wrote: > I used bcond locally and wrongly assumed that fedpkg build would > support --with BCOND and --without BCOND. Instead, the way to activate > it is to change to "%bcond_with check" and then revert to > "%bcond_without check". The only difference with bootstrap is that > "bootstrap" is recognized

I can't reproduce this problem with the recent svn trunk. LLVM 2.9 has lots of fixes for Sparc back-end. So, please at least try with LLVM-2.9. Thanks, On Fri, Sep 16, 2011 at 6:30 PM, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: > Hi Christine, > >> I am using LLVM 2.8 and llvm-gcc 4.2. > > Could you please try svn top-of-tree? Clang is also a better

Anton Korobeynikov wrote: > The patch is incorrect and the problems you're seeing are caused by > your patch, since sparc != sparc64. > In LLVM sense "sparc" means "sparc with ILP32 architecture model", > llvm does not support anything 64 bit in sparc world SparcTargetMachine.h file lists SparcV9TargetMachine as 64-bit machine and SparcV8TargetMachine as

Hi Venkatraman, I am using LLVM 2.8 and llvm-gcc 4.2. The assembly files are attached. In the assembly file, the erroneous result is associated with 'subcc', while the correct ones are associated with 'or'. Thanks a lot! Christine On Fri, Sep 16, 2011 at 2:29 PM, Venkatraman Govindaraju < venkatra at cs.wisc.edu> wrote: > Hello, > > What is your LLVM version?

On Tuesday, 23 June 2020 16.48.53 WEST Tom Callaway wrote: > There are a few of those, but not many. Hi Tom, I noticed that for example in R-assertthat you have used the bcond: %bcond_with check would not it be better to use bootstrap instead to take advantage of: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping I am asking for curiosity since from now on we will

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is

# Summary As a consequence of comparing the RISC-V LLVM MC assembler to the RISC-V GNU assembler I've noticed that a number of targets have quite different handling for pc-relative jumps/branches with immediate integer operands in llvm-mc vs GNU as. I'll admit that this isn't likely to occur in hand-written code (as you'd almost always prefer to use a label), but thought it was

I am trying to understand how LLVM does code generation and I have a couple of questions. I am using LLVM 2.6. First, if I want to change the name of an instruction, all I need to do is to modify the XXXInstrInfo.td, right? Using Sparc as an example, if I wanted to output "mysra" instead of "sra", in SparcInstrInfo.td, I would write, defm SRA : F3_12<"mysra",