similar to: [LLVMdev] storing module level info

Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] storing module level info"

2013 Mar 27
1
[LLVMdev] LLVM pass question
So the switching between mips16 and mips32 on a per function basis seems to basically be working except that asm printer has some kind of issue here. I'm debugging that now. I get this: lc: /home/rkotler/workspace/llvmpb6/include/llvm/MC/MCStreamer.h:224: void llvm::MCStreamer::SwitchSection(const llvm::MCSection*): Assertion `Section && "Cannot switch to a null
2014 Jan 29
6
[LLVMdev] making emitInlineAsm protected
I would like to make the following member of AsmPrinter be protected void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, InlineAsm::AsmDialect AsmDialect = InlineAsm::AD_ATT) const; I have some stubs that I want to emit in MipsAsmParser . Are there any objections to doing this? Reed
2014 Apr 22
3
[LLVMdev] adding comment
I tried out CommentFlag and it looks ideal for this purpose. The attached patch adds a FastISel flag and prints it in the AsmPrinter and the IR dump. You can then call MachineInstr::setAsmPrinterFlag(MachineInstr::FastISel) to set the flag. Some passes seem to be stripping the comment flags though. The one I noticed is the pseudo-instruction expansion pass: # *** IR Dump After Machine Copy
2014 Jan 29
3
[LLVMdev] making emitInlineAsm protected
On 01/28/2014 06:29 PM, Eric Christopher wrote: > Uhhhh... > > -eric > > On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >> I would like to make the following member of AsmPrinter be protected >> >> >> void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, >> InlineAsm::AsmDialect
2013 Oct 15
2
[LLVMdev] module level assembly optimization
On 10/15/2013 01:30 PM, Rafael Espíndola wrote: > On 14 October 2013 21:56, reed kotler <rkotler at mips.com> wrote: >> I would like to do constant pools over an entire module instead of just on a >> per function basis as constant islands does it now. >> >> It seems there are two options for this: >> >> 1) collect the machine functions with their
2014 Jan 29
2
[LLVMdev] making emitInlineAsm protected
On 01/29/2014 02:18 PM, Rafael Espíndola wrote: >> I'd like to just check my code in and then you can look at it in it's >> totality and see if you have >> a better solution . > No! > > If it is the compiler creating instructions, it is not inline > assembly. If you need to print mips16 and mips32 and they are two > independent instruction sets, my guess is
2013 Oct 15
0
[LLVMdev] module level assembly optimization
On 10/15/2013 01:39 PM, reed kotler wrote: > On 10/15/2013 01:30 PM, Rafael Espíndola wrote: >> On 14 October 2013 21:56, reed kotler <rkotler at mips.com> wrote: >>> I would like to do constant pools over an entire module instead of >>> just on a >>> per function basis as constant islands does it now. >>> >>> It seems there are two
2013 May 07
2
[LLVMdev] #APP/#NOAPP
On 05/06/2013 04:23 PM, Eric Christopher wrote: > On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >> Hi Hal, >> >> >> I think that it's perfectly valid to generate inline assembler and it >> looks 1000 times cleaner than if I tried to do this same work with >> selection DAG. >> > I'm pretty sure you're the
2013 Oct 15
5
[LLVMdev] module level assembly optimization
I would like to do constant pools over an entire module instead of just on a per function basis as constant islands does it now. It seems there are two options for this: 1) collect the machine functions with their machine instructions for the whole module, edit them as needed and then call asmprinter for them one at a time. 2) collect all the instruction streams and store them in lists, one
2013 May 06
3
[LLVMdev] #APP/#NOAPP
Hi Hal, I think that it's perfectly valid to generate inline assembler and it looks 1000 times cleaner than if I tried to do this same work with selection DAG. > I hope you don't mind if I play devil's advocate here... > > Why is this so complicated that it would be messy to do, at least in part, at a lower level? I can understand needing IR-level analysis for some kinds of
2014 Jan 31
5
[LLVMdev] emitting function stub for mips16 floating point patch
I'm rewriting this patch for the stubs to not use outputing of raw text. Generating the instructions is very straightforward and that part is done. I'm translating the actual function now. How do you emit an .ent or .globl from asm printer? .type ? .end ?? .section ??? I'm studying the classes now but it should be simple to do so if you know, you can save me some time because this
2013 May 06
2
[LLVMdev] #APP/#NOAPP
I want to disable the #APP/#NOAPP for compiler generated inline asm. Unfortunately, you can change the string APP,NOAPP, but it still will put the "#" there and create a line. In the comments it said that the strings were #APP,#NOAPP but really it's just the part after the comment_string=='#' I'd like to just add a mode flag to AsmPrinter for this. Any objections?
2013 May 06
0
[LLVMdev] #APP/#NOAPP
On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote: > Hi Hal, > > > I think that it's perfectly valid to generate inline assembler and it > looks 1000 times cleaner than if I tried to do this same work with > selection DAG. > I'm pretty sure you're the only one who thinks this. What's so complicated about doing this either at
2013 Mar 27
0
[LLVMdev] LLVM pass question
This seems to work okay. I register both the Mips16 and non Mips16 passes of the instruction selector and then those return false if they are not supposed to be running. Make-check at least passes in this case. So in principle turn on the dual mode now and debug whatever misc is left. For this I insert another pass before the mips16 and non mips16 passes. On 03/27/2013 10:19 AM, Reed Kotler
2013 Mar 27
2
[LLVMdev] LLVM pass question
What I am thinking of now is to just register the MIPS116 and MIPS32 DAGToDAGISel passes and then within run on machine function, I can just return if the current mode indicates that mips16 is needed for example, so the run on machine function for Mips32 would return immediately. On 03/27/2013 10:05 AM, Reed Kotler wrote: > I guess another way to do this is to just register both passes for
2013 May 09
0
[LLVMdev] #APP/#NOAPP
That code looks a little odd but not too awful. I still don't understand what's so wrong/complicated about this. You seem to be of the opinion that injecting asm into a stream ala gcc is a good idea in clang, it really isn't. -eric On Mon, May 6, 2013 at 5:45 PM, reed kotler <rkotler at mips.com> wrote: > On 05/06/2013 04:23 PM, Eric Christopher wrote: >> >> On
2014 Apr 17
2
[LLVMdev] adding comment
Would adding a flag to MachineInstr::MIFlag do the trick? I'm thinking that fast isel could ensure that a flag (e.g. MIFlag::FastISel) is added to the instructions it creates, then the instruction printer could optionally emit a comment for instructions that have this flag. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >
2014 Jan 29
3
[LLVMdev] making emitInlineAsm protected
On 01/29/2014 01:48 PM, Rafael Espíndola wrote: >> So how do I create stubs? >> >> I have specific function stubs that I want to create. >> >> There is no direct object emitter for mips16 at this time. > Print it like any other instruction? > > Cheers, > Rafael I'd like to just check my code in and then you can look at it in it's totality and see
2014 Jan 31
4
[LLVMdev] making emitInlineAsm protected
It may be moot because Reed is currently rewriting the patch to avoid using EmitInlineAsm and EmitRawText but I wanted to question something here. I'm thinking that hasRawTextSupport() shouldn't be the condition used inside EmitInlineAsm. I think it would be more correct to have a useRawTextSupport() predicate that can return hasRawTextSupport() for (sub)targets that haven't
2013 May 06
4
[LLVMdev] #APP/#NOAPP
On 05/06/2013 07:52 AM, Rafael Espíndola wrote: > On 6 May 2013 10:29, reed kotler <rkotler at mips.com> wrote: >> I want to disable the #APP/#NOAPP for compiler generated inline asm. >> >> Unfortunately, you can change the string APP,NOAPP, but it still will put >> the "#" there and create >> a line. >> >> In the comments it said that