similar to: [LLVMdev] Naked functions

I ran into another issue with register scavenger. In my case, I don't need a place on the stack for an emergency spill slot. I have these free mips32 registers, that are not in general very useful for other things, for the emergency spill slot. I can move to and from mips16 (subset of mips32) registers and mips32 registers. I also have a situation where I need two free registers so then

On 11/18/2013 06:34 PM, Jim Grosbach wrote: > On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > >> I don't know ARM hardly at all but... >> >> This comment does not seem to match the code. >> Or maybe tBfar is a BL? > What does the definition of tBfar say? Okay.. but // Far jump // Just a pseudo for a tBL instruction. Needed

On 04/20/2013 02:04 PM, Reed Kotler wrote: > On 04/20/2013 01:30 PM, reed kotler wrote: >> Can I create a "naked" function that has only inline assembler and no >> return IR for example? >> >> If I create just a function will an empty basic block, it's core dumps. >> >> I'm debugging it now. > > Seems that you have to have at least a

Hello Reed, Basic blocks need to end with a terminator instruction. There is an "unreachable" terminator instruction, whose documentation says: "the presence of this instruction indicates some higher level knowledge that the end of the block cannot be reached." (see include/llvm/IR/Instructions.h). I've been able to suppress the return using this. I'm not completely

I don't know ARM hardly at all but... This comment does not seem to match the code. Or maybe tBfar is a BL? Also, how does this work if the destination is greater than 2**21? /// fixupUnconditionalBr - Fix up an unconditional branch whose destination is /// too far away to fit in its displacement field. If the LR register has been /// spilled in the epilogue, then we can use BL to

You mean when I "explicity" use it by calling methods of register scavenger? Right now I'm just allocating virtual registers that will be resolved by the use of register scavenger and I'm also providing an override of the virtual method saveScavengerRegister. In Mips16, I have an extra mips 32 register (not usually very useful since it can only be used in a move instruction)

On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > I don't know ARM hardly at all but... > > This comment does not seem to match the code. > Or maybe tBfar is a BL? What does the definition of tBfar say? > > Also, how does this work if the destination is greater than 2**21? > It doesn’t. IIRC, that’s under the category of “if people start

On 01/09/2013 02:44 PM, Eli Friedman wrote: > On Wed, Jan 9, 2013 at 2:19 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/09/2013 01:19 PM, Sean Silva wrote: >>> On Wed, Jan 9, 2013 at 4:14 PM, reed kotler <rkotler at mips.com> wrote: >>>> Does anyone know offhand where this gets added to clang and where the >>>> hook >>>> for

Hi All! This is the third iteration of my GSoC proposal, which I'm mailing here for feedback. I've already posted the proposal on Melange. The proposal is in two parts. The first, which answers the questions on application template mentioned on Melange is here [1]. I've pasted the most relevant part here: ''' Implement segmented stacks inside LLVM. Once this is

Hi, I've recently been investigating problems with using naked functions in Clang where portions of the stack are overwritten in debug builds. This happens on all architectures I've tested (x86, x64, ARM) and is evident in the LLVM IR itself. With the svn builds of clang, there's an additional problem where undefined results are being introduced First to show what I'm discussing:

Hi! Thanks for the review. What follows is a revised version of the proposal. I'll post this on Melange after getting some more feedback. Segmented stacks for LLVM, GSoC '11 ----------------------------------- * Overview: Goal & Rationale Support segmented (split) stacks in LLVM. The idea is to allocate stack space to a thread incrementally, instead of allocating a (large)

Turned out to be a rather simple fix. Just copied SP to a virtual register in the beginning of the function. Then added an extra operand to the DAGs with stack reference load/store, with the extra operand equal to this virtual register if the Parent of the address is a LOAD/STORE of an 8 or 16 bit quantity. It worked fine. When needed SP got copied to a mips 16 register and when the SP alias

//===----------------------------------------------------------------------===// // FalseParser //===----------------------------------------------------------------------===// class FalseParser : public parser<bool> { public: explicit FalseParser(Option &O) : parser<bool>(O) { } // parse - Return true on error. bool parse(cl::Option& O, StringRef ArgName, StringRef

We already divided out our classes as you did for ARM. The problem here is that we have a store/load byte/halfword to/from a Frame object. We know at that time that it's not going to be possible to store it using SP because there is only such instructions for store/load of a word. What we would want to do is to move SP into a Mips 16 register and then do a indexed load/store off of that

Ok. That's a somewhat different problem, then. Devil will be in the details of what you want to do. A few options. First is to always have a standard frame pointer register available and reference off of that. Caveat: dynamic stack realignment and vararrays muck with that more than a bit. Second is what gcc is doing and reserve a register just for this in addition to the frame register.

One could argue that mclinker is doing something good or not by how it's using this class but I don't see the need for parser<bool> to be final. That is a subjective opinion that mclinker needs to be changed. I think that "final" was added to some of these command line classes to avoid some kind of clang warning. That seems wrong to me that the tools are dictating

I recently examined a bug in a program, and it turned out that the customer was using the section attribute as a form of inline-assembly mechanism, with something like: __attribute__((section("sectionName\nasm\nasm\nasm"))) this was really ugly and not at all obvious where the problem originated. Is there any way of getting LLVM or CLang to validate the name used in the section

Hi John & Ron, I read through the proposal and had a couple of quick observations. 1. The proposed encoding assumes that the epilogue instructions always come at the end of the function -- or rather, just before the next function. If there is a stack protector __stack_chk_fail sequence, or there is NOP padding between functions, then the epilogue cannot be expressed. The proposed encoding

On 03/19/2015 08:55 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 4:30 AM, Reed Kotler <Reed.Kotler at imgtec.com > <mailto:Reed.Kotler at imgtec.com>> wrote: > > One could argue that mclinker is doing something good or not by > how it's using this class > but I don't see the need for parser<bool> to be final. That is a >

Would it be useful for Clang to warn about section names with unusual characters? -Hal ----- Original Message ----- > From: "Reid Kleckner via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Martin J. O'Riordan" <martin.oriordan at movidius.com> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org> > Sent: Wednesday, October 5, 2016