Displaying 6 results from an estimated 6 matches for "mips16instrinfo".
2013 Jan 21
2
[LLVMdev] Troubleshooting Internal Garbage Collection
...p_mi)
// works
bb.erase(p_mi);
// produces the assertion / memory leak.
p_mi->removeFromParent();
I should have looked more closely at the targets that implemented
expandPostRAPseudo() and saw how they got rid of the pseudo instruction. In
particular, the successful line was lifted from bool
Mips16InstrInfo::expandPostRAPseudo(...). Some targets don't eliminate the
pseudo, but rather reconfigure it to be native.
In any case, I don't quite understand why these two seemingly (to me)
equivalent lines of code cause different behavior at run time. For
reference, each of my pseudo instructions expa...
2013 Jan 21
0
[LLVMdev] Troubleshooting Internal Garbage Collection
...> // produces the assertion / memory leak.
> p_mi->removeFromParent();
>
> I should have looked more closely at the targets that implemented
> expandPostRAPseudo() and saw how they got rid of the pseudo instruction. In
> particular, the successful line was lifted from bool
> Mips16InstrInfo::expandPostRAPseudo(...). Some targets don't eliminate the
> pseudo, but rather reconfigure it to be native.
>
> In any case, I don't quite understand why these two seemingly (to me)
> equivalent lines of code cause different behavior at run time. For
> reference, each of my...
2013 Jan 14
0
[LLVMdev] Troubleshooting Internal Garbage Collection
Hi David,
> Previously, I had been testing with only one routine per test .ll file, but I
> thought I'd reached a point where I could test multiple operations at once and
> understand the output. The odd part about this is that the likelihood of seeing
> the above assertion scales with the number of functions in the .ll file. If I
> have one or two functions, I never see it.
2013 Jan 14
2
[LLVMdev] Troubleshooting Internal Garbage Collection
Hello,
I've made some fair progress on a target for 6502 family CPUs recently, but
I've run into an error I'm not sure how to address. I've ruminated over it
for about a week now, trying various things and not having any success. It
seems to scale with the number of routines in my .ll file, which I am
trying to run through llc. I get the following stack dump from an assertion:
2013 Apr 01
0
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
...;MipsInstrInfo.h"
+#include "MipsModuleISelDAGToDAG.h"
+#include "MipsSEFrameLowering.h"
+#include "MipsSEInstrInfo.h"
+#include "MipsSEISelLowering.h"
+#include "MipsSEISelDAGToDAG.h"
+#include "Mips16FrameLowering.h"
+#include "Mips16InstrInfo.h"
+#include "Mips16ISelDAGToDAG.h"
+#include "Mips16ISelLowering.h"
+#include "llvm/Analysis/TargetTransformInfo.h"
#include "llvm/CodeGen/Passes.h"
#include "llvm/PassManager.h"
+#include "llvm/Support/Debug.h"
+#include "llv...
2013 Apr 01
3
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote:
> IMHO the right way to handle target function attributes is to
> re-initialize the target machine and TTI for every function (if the
> attributes changed). Do you have another solution in mind ?
I don't really understand this.
TargetMachine and TTI may be quite expensive to initialize. Doing so for