search for: mcasm

...gle file, it seems fine and even good when the names align. But this seems somewhat less principled than that. Essentially, consistency is a strong argument. I'm looking for strong arguments for keeping them where they are to counter that. > s/AsmParser/IRASM/ (to be distinguished against MCASM) This is a really good one. I would paint this bikeshed LLParser or IRParser. "Asm" has to go though.

...erfectly >> valid approach. >> No two people have 100% the same idea of what is best practices. >> >> The following kind of patch works without adding a mode to asm >> printer >> but in general is harder >> for people to use since they have to get a hook to MCAsm in order to >> change the inline_asm_start/end >> strings. (In AsmPrinter) on a per function basis. >> >> if (OutStreamer.hasRawTextSupport() && >> MAI->getInlineAsmStart()[0]) >> OutStreamer.EmitRawText(Twine("\t")+MAI->getC...

...approach. >>> No two people have 100% the same idea of what is best practices. >>> >>> The following kind of patch works without adding a mode to asm >>> printer >>> but in general is harder >>> for people to use since they have to get a hook to MCAsm in order to >>> change the inline_asm_start/end >>> strings. (In AsmPrinter) on a per function basis. >>> >>> if (OutStreamer.hasRawTextSupport() && >>> MAI->getInlineAsmStart()[0]) >>> OutStreamer.EmitRawText(Twine(&quo...

...be you would not do things this way but I think it's a perfectly valid approach. No two people have 100% the same idea of what is best practices. The following kind of patch works without adding a mode to asm printer but in general is harder for people to use since they have to get a hook to MCAsm in order to change the inline_asm_start/end strings. (In AsmPrinter) on a per function basis. if (OutStreamer.hasRawTextSupport() && MAI->getInlineAsmStart()[0]) OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+ MAI->getIn...

...al namings*. > Are there other names that are poor choices and are lingering in our > codebases? I'm willing to sign up to do more renames while I'm at > this, so this is a chance to get someone else to do the heavy lifting. > =] s/AsmParser/IRASM/ (to be distinguished against MCASM) s/ExecutionEngine/EE/ (or something like buzzword!) ...Takumi

...t; No two people have 100% the same idea of what is best practices. >>>> >>>> The following kind of patch works without adding a mode to asm >>>> printer >>>> but in general is harder >>>> for people to use since they have to get a hook to MCAsm in order to >>>> change the inline_asm_start/end >>>> strings. (In AsmPrinter) on a per function basis. >>>> >>>> if (OutStreamer.hasRawTextSupport() && >>>> MAI->getInlineAsmStart()[0]) >>>> OutStre...

...ay but I think it's a perfectly > valid approach. > No two people have 100% the same idea of what is best practices. > > The following kind of patch works without adding a mode to asm > printer > but in general is harder > for people to use since they have to get a hook to MCAsm in order to > change the inline_asm_start/end > strings. (In AsmPrinter) on a per function basis. > > if (OutStreamer.hasRawTextSupport() && > MAI->getInlineAsmStart()[0]) > OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+ >...

...e 100% the same idea of what is best practices. >>>>> >>>>> The following kind of patch works without adding a mode to asm >>>>> printer >>>>> but in general is harder >>>>> for people to use since they have to get a hook to MCAsm in order to >>>>> change the inline_asm_start/end >>>>> strings. (In AsmPrinter) on a per function basis. >>>>> >>>>> if (OutStreamer.hasRawTextSupport() && >>>>> MAI->getInlineAsmStart()[0]) >>&gt...

...temporary variable Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090831/c58cf066/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: mcasm-vc2005.patch Type: application/octet-stream Size: 625 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090831/c58cf066/attachment.obj>

Hello LLVM & Clang hackers! Based on a discussion with Chris, I would like to propose a Great Renaming of Things for the 3.3-era LLVM and Clang codebase. First and foremost, the two most significant changes I would like to make: 1) llvm/lib/VMCore/... -> llvm/lib/IR/... I've discussed potential names for the VMCore (or LLVMCore) library with lots of folks, and the best idea anyone

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 the strings were #APP,#NOAPP but really it's > just the part after the >

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?

...> arguments for keeping them where they are to counter that. Right. IR is central to the compiler backend, but clients of clang or higher level things (who do use a lot of stuff from llvm/* also, directly) don't necessarily use IR). >> s/AsmParser/IRASM/ (to be distinguished against MCASM) > > This is a really good one. > > I would paint this bikeshed LLParser or IRParser. "Asm" has to go though. Personally, I'd like to get llvm/IR and CodeGen->IRGen done, then discuss other movements in separate threads :). But yes, there is a lot of progress that c...