search for: x86machinefunctioninfo

In lib/Target/X86/X86COFFMachineModuleInfo.h we have: class X86MachineFunctionInfo; ... class X86COFFMachineModuleInfo : public MachineModuleInfoImpl { ... typedef std::map<const Function*, X86MachineFunctionInfo> FMFInfoMap; FMFInfoMap FunctionInfoMap; ... }; At this point in the translation unit X86MachineFunctionInfo is an incomplete ty...

...have strong feelings about how this particular situation should be fixed, but this solution seems the simplest to me. I do not anticipate a fix from the standards committee on this matter, though if anyone would like to pursue this course of action, I can certainly help with that. #include "X86MachinefunctionInfo.h" added to X86COFFMachineModuleInfo.h to make X86MachineFunctionInfo a complete class before it is used to instantiate std::map. #include <ostream> added to TargetData.cpp to bring these formatting prototypes into scope. --- -Howard -------------- next part -------------- A non-text...

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is

...w this particular situation should be fixed, but > this solution seems the simplest to me. I do not anticipate a fix > from the standards committee on this matter, though if anyone would > like to pursue this course of action, I can certainly help with that. > > #include "X86MachinefunctionInfo.h" added to > X86COFFMachineModuleInfo.h to make X86MachineFunctionInfo a complete > class before it is used to instantiate std::map. > > #include <ostream> added to TargetData.cpp to bring these formatting > prototypes into scope. > > --- > > -Howard &gt...

...GR8Class::iterator GR8Class::allocation_order_end(const MachineFunction &MF) const { const TargetMachine &TM = MF.getTarget(); const TargetFrameLowering *TFI = TM.getFrameLowering(); const X86Subtarget &Subtarget = TM.getSubtarget<X86Subtarget>(); const X86MachineFunctionInfo *MFI = MF.getInfo<X86MachineFunctionInfo>(); // Does the function dedicate RBP / EBP to being a frame ptr? if (!Subtarget.is64Bit()) // In 32-mode, none of the 8-bit registers aliases EBP or ESP. return begin() + 8; else if (TFI->hasFP(MF) || MFI->getRe...

...d get the > shape information with limited code change on existing RA? > For each virtual register, getRegAllocationHints could just recompute the shape information. If this isn't a constant-time operation, however, you'll probably want to cache the computed shape requirements in X86MachineFunctionInfo. You can add a map from registers to shape information in that class, and accesses it from getRegAllocationHints. You can store information about the physical registers there too. Regarding the physical registers, you can grab this information in the pre-rewrite phase. Override addPreRewrite in...

Hello, I am working on a project where I need to insert some logic before each machine basic block. In particular, it involves setting some global variables and calling a function. I'm able to add the instructions and verify they get added, but when the compiled program runs, it stops with a segfault. For brevity, I'm not sharing the whole code here but basically I have a X86

...to store and get the shape information with limited code change on existing RA? For each virtual register, getRegAllocationHints could just recompute the shape information. If this isn't a constant-time operation, however, you'll probably want to cache the computed shape requirements in X86MachineFunctionInfo. You can add a map from registers to shape information in that class, and accesses it from getRegAllocationHints. You can store information about the physical registers there too. Regarding the physical registers, you can grab this information in the pre-rewrite phase. Override addPreRewrite in X8...

...ocGreedy, getRegAllocationHints is called for each virtual register. For virtual tile registers, look at the passed VirtRegMap, etc. for already-assigned tile virtual registers with different shape requirements as the current virtual register (you'll need to cache the shape requirements in X86MachineFunctionInfo for this to be efficient), and return a hints list consisting of all other non-reserved tile registers.  2. To support RegAllocFast, which doesn't use getRegAllocationHints, you would need to make the configuration regions small enough that it doesn't matter (and if you're doing th...

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

Best guess is that you're clobbering something in the red zone. https://en.wikipedia.org/wiki/Red_zone_(computing). It's not guarantee that the area of the stack above the stack pointer is unused. I think you can check if the redzone is used by checking getUsesRedZone() in X86MachineFunctionInfo. If the red zone is used, its not safe to insert a push/pop. I think you can turn off the red zone by passing -mno-red-zone to clang. ~Craig On Thu, Nov 12, 2020 at 10:18 AM vignesh babu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > I am working on a project wh...

On Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

...ect tailcall attribute so that the target can rely on the tailcall + // attribute indicating whether the call is really eligible for tail call + // optimization + CheckDAGForTailCallsAndFixThem(DAG, TLI); + check -> Check to start a sentence. :-) + // Skip the RETADDR move area + X86MachineFunctionInfo *X86FI = MF.getInfo<X86MachineFunctionInfo>(); + int32_t TailCallReturnAddrDelta = X86FI->getTCReturnAddrDelta(); Why using int32_t instead of int in some of the places? Nothing "wrong" with it, just inconsistent. + // If there is an SUB32ri of ESP immediately bef...

Hi Hal, The proposal is attractive to me, but there is something I still can't figure out. Let's take below MIR as an example. We assume we have 256 register classes (vtile1x1, vtile1x2, ..., tile16x16). 1. After instruction selection, the pseudo AMX instruction is generated. The name of pseudo instructions have 'P' prefix. Now all the AMX pseudo instruction take vtile as

...r.cpp for Release+Asserts build llvm[3]: Compiling CallPrinter.cpp for Release+Asserts build llvm[3]: Compiling LoopIdiomRecognize.cpp for Release+Asserts build llvm[3]: Compiling GlobalsModRef.cpp for Release+Asserts build llvm[3]: Compiling DIEHash.cpp for Release+Asserts build llvm[3]: Compiling X86MachineFunctionInfo.cpp for Release+Asserts build llvm[3]: Compiling LoopInstSimplify.cpp for Release+Asserts build llvm[3]: Compiling IPA.cpp for Release+Asserts build llvm[3]: Compiling X86PadShortFunction.cpp for Release+Asserts build llvm[3]: Compiling DbgValueHistoryCalculator.cpp for Release+Asserts build llvm[3...