search for: armasmprint

Sharing with the mailing list... Please, see below. On 9 January 2017 at 23:45, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Hi Dean, > > I have seen that you removed the following code from ARMAsmPrinter.cpp in > revision 290858: > // Emit the XRay table for this function. > EmitXRayTable(); > > Was this done by mistake or on purpose? > > Without this call, xray_instr_map gets empty in the executable, so that > XRay doesn't patch anything. While implementing the ta...

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG'...

...pe=box,style=filled,color=olivedrab1]; AsmParser [shape=box,style=filled,color=olivedrab1]; Archive [shape=box,style=filled,color=olivedrab1]; Analysis [shape=box,style=filled,color=olivedrab1]; ARMInfo [shape=box,style=filled,color=olivedrab1]; ARMCodeGen [shape=box,style=filled,color=olivedrab1]; ARMAsmPrinter [shape=box,style=filled,color=olivedrab1]; ARMAsmParser [shape=box,style=filled,color=olivedrab1]; subgraph clusterARM { ARMAsmParser; ARMAsmPrinter; ARMInfo; ARMCodeGen; } subgraph clusterX86 { X86AsmParser; X86AsmPrinter; X86Info; X86CodeGen; } ARMAsmParser -> ARMInfo ARMAsmParser -> M...

...e the tests for ARM. Oleg ________________________________________ From: Renato Golin <renato.golin at linaro.org> Sent: Monday, January 9, 2017 11:50 PM To: Serge Rogatch Cc: Dean Michael Berris; LLVM Developers; Oleg Ranevskyy Subject: Re: [llvm-dev] Removed a call to EmitXRayTable() from ARMAsmPrinter On 9 January 2017 at 20:47, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Without this call, xray_instr_map gets empty in the executable, so that >> XRay doesn't patch anything. While implementing the tail call handling, I am >> reverting this chan...

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be invoked in the > MC'ized path for...

...vm: http://www.llvm.org/bugs/show_bug.cgi?id=9582 Basically, ARM, Thumb and data mapping symbols should have been exported in the ELF file, so the linker can work correctly. I can do the change and create some test cases, but I haven't been paying much attention to recent MC developments. Is ArmAsmPrinter the place to change for that, or is there an MC equivalent that would be a better fit? thanks, --renato

> As Oleg points out, apparently the way we've configured the XRay tests in compiler-rt/... excludes running tests on non-64-bit platforms. arm7 is definitely not 64-bit and therefore means we've not been running those tests. :( I believe that for this particular case one does not need to have execution tests - you'd simply need to check for expected output and that's it. --

...Tag_ABI_FP_number_model Suppose there are two functions in a module which have different sets of function attributes. One function has attributes for "-ffast-math" (foo1) and the other (foo0) has attributes for "-fno-fast-math". In that case, which set of eabi attributes should ARMAsmPrinter::emitAttributes emit? ARMAsmPrinter::emitAttributes is called once at the start of a file (not once per every function), so I assume it has to merge those attributes which have different values or reject the IR if it discovers incompatibilities. define double @foo0(double %a) #0 { entry: %add...

..._______________________ >> From: Renato Golin <renato.golin at linaro.org> >> Sent: Monday, January 9, 2017 11:50 PM >> To: Serge Rogatch >> Cc: Dean Michael Berris; LLVM Developers; Oleg Ranevskyy >> Subject: Re: [llvm-dev] Removed a call to EmitXRayTable() from ARMAsmPrinter >> >> On 9 January 2017 at 20:47, Serge Rogatch via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>>> Without this call, xray_instr_map gets empty in the executable, so that >>>> XRay doesn't patch anything. While implementing the tail call h...

...show_bug.cgi?id=9582 > > Basically, ARM, Thumb and data mapping symbols should have been > exported in the ELF file, so the linker can work correctly. > > I can do the change and create some test cases, but I haven't been > paying much attention to recent MC developments. Is ArmAsmPrinter the > place to change for that, or is there an MC equivalent that would be a > better fit? The increasingly misnamed ARMAsmPrinter.cpp is the MC lowering pass. There is no non-MC based printer anymore, so you'll only have to change one place. In particular, have a look at ARMAsmPrinte...

...ound the first use for MachineConstantPoolValue :-) Creating the constant is easy, but I have two problems: 1) what are the methods getExistingMachineCPValue and AddSelectionDAGCSEId supposed to do? 2) printing is hard because we are outside the AsmPrinter. In my current hack I am printing from ARMAsmPrinter::EmitMachineConstantPoolValue :-( Since this problem might also be significant to x86 (see my previous email), maybe we should just teach the pool printer to emit ".weak" directives... Best Regards, Rafael P.S.: rest assured that what is attached is just a demo hack and will not be c...

...by gnu assembler and no .o file is generated at all. Currently LLVM emits ".cpu" directive, but totally forgets about ".fpu", and this causes problems. My proposed patch is available in LLVM bug 8931, and I'm also pasting it here for more convenience: Index: lib/Target/ARM/ARMAsmPrinter.cpp =================================================================== --- lib/Target/ARM/ARMAsmPrinter.cpp (revision 123053) +++ lib/Target/ARM/ARMAsmPrinter.cpp (working copy) @@ -458,7 +458,13 @@ AttrEmitter->EmitAttribute(ARMBuildAttrs::THUMB_ISA_use, 1); } - // FIXME: Em...

...r the fact? I am guessing I need to use an MCFixup? How do I get an MCExpr to evaluate a method for the subsection size? Is there an equivalent use in the places using MCFixup? Do I need to add a new subclass to MCExpr for doing this? JimG, can you please comment on the MachO specific parts in the ARMAsmPrinter.cpp? Is there an example of a "subsection size" that is "Fixed up" after all the blobs that go into that subsection are emitted? The closest examples I could find weren't that close :-( (Matter of fact, for ELF, it looks like the section sizes are actually calculated after...

On Fri, Feb 25, 2011 at 12:16 PM, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > On Thursday 03 February 2011 14:14:28 Renato Golin wrote: >> On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> > wrote: >> > I have submitted a bug some time ago to LLVM bugtracker: >> > http://llvm.org/bugs/show_bug.cgi?id=8931 >>

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

Hi Tim, Thank you for your answer. *We've fairly recently fixed a bug that looks very similar (r238680,which was well after 3.6)* If I wanted to back port that to 3.5 where should I look at? Where in the ARM backend the decision to relax an instruction is taken? *That's weird. Even with "-filetype=obj" (the bug only occurs whendirectly writing an object file)? Not that it

...) const { return Kind == ARMCP::CPValue; } + bool isDataSegmentJumpTable() const { + return Kind == ARMCP::CPDataSegmentJumpTable; } unsigned char getPCAdjustment() const { return PCAdjust; } virtual int getExistingMachineCPValue(MachineConstantPool *CP, Index: lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp =================================================================== --- lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp (revision 72728) +++ lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp (working copy) @@ -33,13 +33,19 @@ #include "llvm/ADT/Statistic.h" #include "llvm/ADT/StringExt...

On Thursday 03 February 2011 14:14:28 Renato Golin wrote: > On 3 February 2011 10:25, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote: > > I have submitted a bug some time ago to LLVM bugtracker: > > http://llvm.org/bugs/show_bug.cgi?id=8931 > > Hi Siarhei, > > This is a really silly bug with a simple fix. > > We have a similar patch here

...eed to use an MCFixup? > How do I get an MCExpr to evaluate a method for the subsection size? > Is there an equivalent use in the places using MCFixup? > Do I need to add a new subclass to MCExpr for doing this? > > JimG, can you please comment on the MachO specific parts in the > ARMAsmPrinter.cpp? Is there an example of a "subsection size" that is > "Fixed up" after all the blobs that go into that subsection are > emitted? The closest examples I could find weren't that close :-( > (Matter of fact, for ELF, it looks like the section sizes are actually &...

...ase for >> supporting movt/movw fixup emission? >> The call stack seems to be: >> >> #0 ARMMCCodeEmitter::getBinaryCodeForInstr >> #1 ARMMCCodeEmitter::EncodeInstruction >> #2 MCELFStreamer::EmitInstToData >> #3 MCObjectStreamer::EmitInstruction >> #4 ARMAsmPrinter::EmitInstruction >> <arm-mc-elf-s08.patch>_______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > >