search for: machinefunctioninfo

2015-04-28 10:09 GMT-07:00 Krzysztof Parzyszek <kparzysz at codeaurora.org>: > Looks good. How are you planning to "assemble" the MI-level YAML > description into the actual in-memory IR? I plan on developing a parser for the new text format for the machine instructions. This parser will parse instructions, operands and memory operands, and it will after run the machine

...> > 1. As many options as possible should be queried via the back-end directly > rather than relying upon objects holding onto these options, I’m not quite sure what you mean by “queried via the back-end directly”. Here’s what I propose: When constructing a target-specific instance of MachineFunctionInfo, any “simple” function attributes that the target backend may need to query should be read from the IR (per goal 3 below) and recorded in the MachineFunctionInfo object. Target-independent function attributes can be handled in the MachineFunctionInfo base class. The information will then be retri...

...As many options as possible should be queried via the back-end directly >> rather than relying upon objects holding onto these options, > > I’m not quite sure what you mean by “queried via the back-end directly”. Here’s what I propose: When constructing a target-specific instance of MachineFunctionInfo, any “simple” function attributes that the target backend may need to query should be read from the IR (per goal 3 below) and recorded in the MachineFunctionInfo object. Target-independent function attributes can be handled in the MachineFunctionInfo base class. The information will then be retri...

...ions as possible should be queried via the back-end directly >>> rather than relying upon objects holding onto these options, >> >> I’m not quite sure what you mean by “queried via the back-end directly”. Here’s what I propose: When constructing a target-specific instance of MachineFunctionInfo, any “simple” function attributes that the target backend may need to query should be read from the IR (per goal 3 below) and recorded in the MachineFunctionInfo object. Target-independent function attributes can be handled in the MachineFunctionInfo base class. The information will then be retri...

Hi all, This is my proposal for how to solve the problem we have with function attributes that affect code generation changing between functions. (This is mostly a problem for LTO.) Please take a look at this proposal, and let me know if you have any questions or comments. Cheers! -bw CodeGen Context =============== The back-end's

I'm trying to access the MachineFunctionInfo structure from a pre-ISel pass. In order to do this I have to get access to the MachineFunction and then call getInfo(). Currently in my pass I request it via: void AMDILBarrierDetect::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<MachineFunctionAnalysis>(); FunctionPass...

...39;noinstrument' attribute during Target lowering? I would like to check if this is present on a function quite late in the process when I am performing normal Target lowering and Target Frame lowering actions, but I can't find the appropriate query in the 'MachineFunction' or 'MachineFunctionInfo' interfaces. Thanks, MartinO -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161220/40e31129/attachment.html>

...e ‘noinstrument’ > attribute during Target lowering? I would like to check if this is present > on a function quite late in the process when I am performing normal Target > lowering and Target Frame lowering actions, but I can’t find the > appropriate query in the ‘MachineFunction’ or ‘MachineFunctionInfo’ > interfaces. > > > > Thanks, > > > > MartinO > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- nex...

...er a function has the ‘noinstrument’ attribute during Target lowering? I would like to check if this is present on a function quite late in the process when I am performing normal Target lowering and Target Frame lowering actions, but I can’t find the appropriate query in the ‘MachineFunction’ or ‘MachineFunctionInfo’ interfaces. Thanks, MartinO _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An...

Dear LLVM developers, Just as LLVM IR can be read/write via persistent bitcode (*.bc *.ll) files, is there any similar implementation in LLVM to read/write Machine IR (MIR) via a persistent file? If not and I would like to add it (e.g. for ARM or RISC-V), could you direct me materials and/or LLVM source code modules where I should start with? Best Regards, Lele Ma -------------- next part

Valentin, in terms of limitations as Sean pointed out, an important one is that .mir doesn't have MachineFunctionInfo which may result in failure on accesses to global variables due to use of register X2. The verifier considers it an undefined register. Also, it's probably easier to reduce test cases using bugpoint starting from an IR test case. With the code you provided, I get a different crash than what you...

...at looking at the pass pipeline and the IR and get a reproducer that way! Thanks, Valentin On Tue, 20 Mar 2018 at 07:51 Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > Valentin, > in terms of limitations as Sean pointed out, an important one is that .mir > doesn't have MachineFunctionInfo which may result in failure on accesses to > global variables due to use of register X2. The verifier considers it an > undefined register. > Also, it's probably easier to reduce test cases using bugpoint starting > from an IR test case. With the code you provided, I get a different...

...PC64RegisterInfo.cpp Index: lib/Target/Skeleton/SkeletonTargetMachine.cpp Index: lib/Target/SparcV8/SparcV8AsmPrinter.cpp Index: lib/Target/SparcV8/SparcV8ISelSimple.cpp Index: lib/Target/SparcV8/SparcV8TargetMachine.cpp Index: lib/Target/SparcV9/EmitBytecodeToAssembly.cpp Index: lib/Target/SparcV9/MachineFunctionInfo.cpp Index: lib/Target/SparcV9/MachineFunctionInfo.h Index: lib/Target/SparcV9/MappingInfo.cpp Index: lib/Target/SparcV9/MappingInfo.h Index: lib/Target/SparcV9/SparcV9BurgISel.cpp Index: lib/Target/SparcV9/SparcV9FrameInfo.h Index: lib/Target/SparcV9/SparcV9InstrForest.h Index: lib/Target/SparcV9/S...

...et a > reproducer that way! > > Thanks, > Valentin > > On Tue, 20 Mar 2018 at 07:51 Nemanja Ivanovic <nemanja.i.ibm at gmail.com> > wrote: > >> Valentin, >> in terms of limitations as Sean pointed out, an important one is that >> .mir doesn't have MachineFunctionInfo which may result in failure on >> accesses to global variables due to use of register X2. The verifier >> considers it an undefined register. >> Also, it's probably easier to reduce test cases using bugpoint starting >> from an IR test case. With the code you provided, I...

...the PTX back-end will never tie into the JIT compiler. After experimenting with the conversion a bit, the main problem I'm having right now is that MCInst instances do not tie back to a MachineFunction, which is required (at least without severe hacks) in the PTX back-end to refer back to the MachineFunctionInfo struct for register names, etc. I'm sure there are ways around this, but it would be a substantial up-front effort. With that said, what are the advantages of making a back-end assembly printer MC-aware? Is it even worth the effort for this back-end, given its rather unique constraints? The...

...> Thanks, >> Valentin >> >> On Tue, 20 Mar 2018 at 07:51 Nemanja Ivanovic <nemanja.i.ibm at gmail.com> >> wrote: >>> >>> Valentin, >>> in terms of limitations as Sean pointed out, an important one is that >>> .mir doesn't have MachineFunctionInfo which may result in failure on >>> accesses to global variables due to use of register X2. The verifier >>> considers it an undefined register. >>> Also, it's probably easier to reduce test cases using bugpoint starting >>> from an IR test case. With the code...

On 2015-04-28 19:14, Quentin Colombet wrote: > Personally I would rather not have to write YAML inputs but instead > resort on the what the machine dumps look like. That being said, I can > live with YAML :). > YAML is what is suggested in the FIXME for the textual Machine IR, so that might be the motivation behind Alex's choice. I sort of agree that it could be better to go

Hi, As a way to learn LLVM, I'm trying to write a backend for the Microchip PIC18 8-bit microcontroller. On this device, the hardware stack is very small and is used only for storing function return addresses. A "real" software stack implementation is not very efficient because of the limited instruction set, so for all the non-reentrant functions I've decided to use a similar

Hello Valentin, To generate a mir test case i think the process is to first create an IR file by passing '-S -emit-llvm' to clang, then you can feed that file into llc and use stop-before to get the mir just before the if-converter pass, eg: `llc -stop-before=if-converter -simplify-mir -o test.mir test.ll`. Also there is a MIR language reference: https://llvm.org/docs/MIRLangRef.html

Hello, I am trying to isolate an assertion failure in if-converter (on PPC) and I generated a textual debuglog with: ``` LLVM_ARGS=-print-before-all -print-module-scope -filter-print-funcs=japi1__require_7687 ``` and after splicing out the the MIR before the if-converter pass I would like to run `llc -march=ppc64le -run-pass=if-converter input.mir` so that I can start minimising the MIR. This