search for: basictransforminfopass

On 03/28/2013 12:22 PM, Nadav Rotem wrote: > Hi Reed, > > On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > >> As for the BasicTransformInfoPassass, for this dual mode I'm using >> createNoTargetTransformInfoPass right now. > > So, MIPS does not need LSR, LowerSwitch and other optimizations that > depend on TTI ? > As an experiment, I built a flavor of llvm inside of Mips that always uses createNoTargetTransformInfo...

...compilation on a per function basis working. I need to clean up some things and then will push the change. I managed to do everything without needing to change anything in target independent code thus far. It was a fun puzzle to solve as to how to do this using only the given APIs. As for the BasicTransformInfoPassass, for this dual mode I'm using createNoTargetTransformInfoPass right now. I will solve this issue of the BasicTransformInfoPass being immutable after this initial checking which gets all the functionality. I was able to make in a function pass but ran into some issues so I put that aside...

Hi Reed, On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com> wrote: > As for the BasicTransformInfoPassass, for this dual mode I'm using createNoTargetTransformInfoPass right now. So, MIPS does not need LSR, LowerSwitch and other optimizations that depend on TTI ? > I will solve this issue of the BasicTransformInfoPass being immutable after this initial checking which gets all the functional...

...0x00007f0f50836941 __assert_fail + 241 7 llc 0x000000000096d740 8 llc 0x0000000000f7d1ec llvm::AsmPrinter::EmitFunctionHeader() + 160 Maybe someone knows how this dependency can exist from switching subtarget information. If so, TIA. My additional work is to turn BasicTransformInfoPass into a function pass from an immutable pass but I don't need that right now for this functionality in mips16/32 dual mode. It will just generate worse code until I solve that. Reed On 03/27/2013 11:17 AM, Reed Kotler wrote: > This seems to work okay. > > I register both the Mips16...

This seems to work okay. I register both the Mips16 and non Mips16 passes of the instruction selector and then those return false if they are not supposed to be running. Make-check at least passes in this case. So in principle turn on the dual mode now and debug whatever misc is left. For this I insert another pass before the mips16 and non mips16 passes. On 03/27/2013 10:19 AM, Reed Kotler

What I am thinking of now is to just register the MIPS116 and MIPS32 DAGToDAGISel passes and then within run on machine function, I can just return if the current mode indicates that mips16 is needed for example, so the run on machine function for Mips32 would return immediately. On 03/27/2013 10:05 AM, Reed Kotler wrote: > I guess another way to do this is to just register both passes for

Hi Reed, We will need to reconstruct the target machine and the TTI chain when the function attributes change. We currently don't have code for doing that but I suggest that you talk with Bill Wendling about the best way to implement this. Thanks, Nadav On Mar 22, 2013, at 11:30 AM, Reed Kotler <rkotler at mips.com> wrote: > Just realized that BasicTransformInfoClass is an

Just realized that BasicTransformInfoClass is an immutable pass. Not sure how to reconcile this with fact that there will be different answers needed depending on the subtarget. Seems like BasicTansformInfoClass should become a function pass that does not modify anything. On 03/22/2013 09:43 AM, Reed Kotler wrote: > Another way to do this would to be to have a reset virtual function >