similar to: [LLVMdev] How basic block layout is determined during scheduling?

Hi Yang, > bnz R2, LBB0_34 > > I do not have any clue what happens when compiling with -O2. > Can someone make a suggestion? Is the "bnz" instruction marked "isBarrier" in your TableGen files? If so, that would mean LLVM considers fallthrough impossible and decides it can move LBB0_33 around at will. It's still very odd that it thinks it can put it

Hi All, For various obscure reasons I'd like to detect the condition when X86 CALL instruction immediately precedes a function epilogue in the final emitted code, and insert a NOP between them if that happens. My initial attempt at it looked like this: MachineBasicBlock& MBB; MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin()

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

Hi all, I got a silly bug when compiling our project with the latest Clang. Here's the outputted assembly: > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4] > ldr r6, [r4, r6, lsl #2] > bx r6 For the code to execute correctly, either the _ldr_ should be a _ldrne_ instruction or the _ldreq_ instruction should be removed. The error seems to

On Tue, Oct 10, 2017 at 4:48 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 10/9/2017 3:10 AM, Gaël Jobin via llvm-dev wrote: > > Hi all, > > I got a silly bug when compiling our project with the latest Clang. Here's > the outputted assembly: > > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4]

Hi, I have a number of SPLUS scripts that I wish to run in R. Can you point me to the right FAQ or help area to do this? Cheers Andy Andy Donaldson Head Of Market Risk Institutional Markets & Services Bank of New Zealand Phone: +64 4 474 6937 Mob No: +64 29 222 0050 CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee

Fernando, The code there should be more or less functional, though it's not currently used by anything. Eventually it should probably be moved to a method on MachineBasicBlock. The API breakage you're seeing is because some methods moved around. Feel free to fix it. :-) --Owen On Jan 26, 2008, at 6:31 PM, Fernando Magno Quintao Pereira wrote: > > Hi LLVMers, > >

Hi LLVMers, what is the status of breaking critical edges in machine functions? I just compiled the top of the LLVM tree, and I found llvm/CodeGen/BreakCriticalMachineEdge.h. But this file seems not to be up-to-date with the other classes in the top of the tree. For instance, it calls isTerminatorInstr on llvm::TargetInstrInfo, but this method is no longer there. If I want to break

I want to be able to do two things with LLVM (both just before code emission): 1. Insert a MachineBasicBlock just before a MachineBasicBlock. There is a function called AddPredecessor(). However, the comment says that it does not update the actual CFG. I want to redirect all CFG edges that are incoming to this MachineBasicBlock to the new one I create, and add just one outgoing edge (no branch)

Greetings, LLVM devs, For the past few weeks, I have been putting together a 6502 backend for LLVM. The 6502 and its derivatives, of course, have powered countless microcomputers, game consoles and arcade machines over the past 40 years. The backend is just an experimental hobby project right now. The code is available here: <https://github.com/beholdnec/llvm-m6502>. This branch introduces

The parts of klibc specific to the parisc architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 078d6614054391efe17093f8d70340e2c0644ffb tree 63a4bf899e5ca2ef3c0a8e9ef3098273012f7a33 parent ebd2860ad3dc19cb11fd5b9cc235cab54e9165f4 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:36 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Hi Laine, Sorry to disturb you. It seemed this issue had been fixed in libvirt-1.2.2/libnl-3.2.22/linux-3.12. But we still got the error on PowerPC platform. I'll appreciate if you could give any suggestion. We are not sure if any netlink implementation in kernel space is missed. The scenario is a little complicated. We installed internal PF and VF kernel modules and want to use

Hello Lang, thanks for the suggestion :) it's very interesting. I'll take a read to the email you've pointed out there to understand how it works. Btw, does this mean that only your allocator is able to handle or support this type of constraint? As a follow up to my previous email, the following code is a real example of what i was explaining, Lang this example is exactly why i need

Reimplement __common_syscall in assembler. The 32-bit ABI says that the fifth and sixth arguments to the function are passed on the stack, but our syscall ABI says they are passed in %arg4 and %arg5 like the 64-bit ABI. Also, tried to optimize the code slightly by making use of the cmpb delay slot to load the errno return of -1. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> diff

Hi Jacob, At this point, I suspect there is a problem with maintaining liveness information during branch folding. Here is what I see: I have a basic block ready for branch optimization, that computes a predicate p10 on which a conditional branch depends. Notice that this is in the stage with physical registers. BB#2: derived from LLVM BB %while.cond.preheader Live Ins: %R3 %R5

On Wed, Oct 31, 2012 at 09:13:43PM +0100, Bjorn De Sutter wrote: > Hi all, > > I am working on a CGRA backend (something like a 2D VLIW), and we also absolutely need predication. I extended the IfConversion pass to allow it to be executed multiple times and to predicate already predicated code. This is necessary to predicate code with nested conditional statements. At this point, we

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.

So I thought I'd try to use the documentation on llvm backends to try to create a DLX backend. I think I've got most of the stuff for the .td files done but I've got some problems. * Do I need to represent the PC in my XXXRegisterInfo.td file; the branch instruction effects it but you can directly access it ... I'm thinking not. * In my Instruction subclasses (in

Commit-ID: b71dd57f6a784962681ac05aa686b28db8668609 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=b71dd57f6a784962681ac05aa686b28db8668609 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Mon, 21 Jan 2019 03:55:35 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Mon, 21 Jan 2019 03:55:35 +0000 [klibc] parisc: Fix vfork() The

On May 31, 2013, at 4:07 PM, Joe Matarazzo <joe.matarazzo at gmail.com> wrote: > The register coalescer treats virtual super register classes -- a sequential register range composed of multiple hardware registers -- as a register with sub registers. When making coalescing decisions it thinks that the virtual super reg interferes with sub reg instances, even though in reality they