You're right - I was just trying to find a quick and dirty way to tag the inputs and meet the requirements so that I could move forward in the experimentation. I have it working now (with the incorrect implementation) after adding a few more restrictions in type inference for MOD, but I'll start investigating now on how to do this the _right_ way, as you described below. Thanks again...
- Shasank On Fri, Jan 7, 2011 at 1:15 PM, [email protected] <[email protected]>wrote: > Hi Shasank, > > > I also added defined the virtual function > > RequiredInputRepresentation() in the HMod class so that it returns > > Representation::Tagged(). > > This is the _wrong_ thing to do. By requiring tagged inputs to HMod > you effectively disabled untagged versions (int32 and double one) of > modulo on all platforms (including ia32). You should not impose such > strict constraints --- leave representation inference to hydrogen. > > You have to handle tagging and untagging inside the code you are > emitting for LModI. > > > That forces the inputs to be tagged, but I don't think it changes the > result to be so. > > Representation of the output for HMod is inferred from representations > of inputs. Thus requiring tagged inputs forces HMod to have tagged > output. > > -- > Vyacheslav Egorov. > > > On Jan 7, 9:41 pm, Shasank Chavan <[email protected]> wrote: > > Hi Vyachesla. I got rid of UseRegister() for the divisor and replaced > with > > UseFixed(). I also added defined the virtual function > > RequiredInputRepresentation() in the HMod class so that it returns > > Representation::Tagged(). That forces the inputs to be tagged, but I > don't > > think it changes the result to be so. My testing seems to indicate that, > as > > I'm always getting double the result expected from the mod stub when > printed > > out (smi). I'll look into how this is done. > > > > Thanks so much for your response. Calling the stub is definitely not the > > right approach, but I wanted to go through the exercise to learn. Thanks > > again. > > > > - Shasank > > > > On Thu, Jan 6, 2011 at 1:34 PM, Vyacheslav Egorov <[email protected] > >wrote: > > > > > > > > > > > > > > > > > Hi Shasank, > > > > > I am pretty sure that implementing LModI/LDivI is not the simplest > > > problem in ARM port cause ARM does not have integer division in the > > > instruction set. > > > > > > Anyways, I'm now getting an assert during register allocation while > > > > splitting a live range: > > > > > My guess would be that you still have > > > > > LOperand* divisor = UseRegister(instr->right()); > > > > > in LChunkBuilder::DoMod(). > > > > > Instructions marked as calls can only use fixed registers. > > > > > Is your code based on V8 revision preceding r6149 > > > (http://code.google.com/p/v8/source/detail?r=6149)?After<http://code.google.com/p/v8/source/detail?r=6149%29?After>r6149 > > > using > > > a non-fixed register for an instruction marked as call triggers a more > > > meaningfull assertion. > > > > > > So my first question is, is this a viable approach? > > > > > We definetely do not want to go into generic stub for every untagged > > > integer division. > > > > > But that sounds OK if you just want to increase test coverage. > > > > > > __mov instructions to get the operands into registers r0 and r1 > > > > > LDivI/LModI have the following semantics: they get untagged int32 > > > inputs and either return untagged int32 output or deoptimize if the > > > result cannot be represented in int32. > > > > > Thus you can't just pass inputs to generic stub and return what stub > > > returns. You have to tag inputs and convert output to untagged int32 > > > (or deoptimize). > > > > > But as I said previously calling generic stub probably is not the best > > > thing performance wise. > > > > > -- > > > Vyacheslav Egorov > > > > > On Thu, Jan 6, 2011 at 9:36 PM, Shasank Chavan <[email protected]> > wrote: > > > > Hi. I'm new to v8 development, so forgive me if I misstate anything. > > > > In an effort to understand code generation better, I'm trying to > > > > implement some of the missing ARM functionality during lithium code > > > > generation. In particular, I thought implementing the integer MOD > > > > operator would be a good start. The first approach I'm taking is to > > > > simply call a stub which will evaluate the operation. Here's what I > > > > did (and then soon after I'll explain the error I'm getting): > > > > > > 1. Modified LCodeGen::DoModI() by removing the Abort() and replacing > > > > it with a) __mov instructions to get the operands into registers r0 > > > > and r1, and b) Instantiating GenericBinaryOpStub and then calling > > > > CallCode() on it. > > > > > > 2. In LChunkBuilder::DoMod() I added a "MarkAsCall()", so that the > MOD > > > > is treated as a call. > > > > > > Note, I made several of these changes incremenatlly after observing > > > > various assertion failures, so I very well could be taking a > > > > completely incorrect approach here. > > > > > > Anyways, I'm now getting an assert during register allocation while > > > > splitting a live range: > > > > > > # > > > > # Fatal error in src/lithium-allocator.cc, line 2009 > > > > (LAllocator::FindOptimalSplitPos()) > > > > # CHECK(start_instr <= end_instr) failed > > > > # > > > > > > So my first question is, is this a viable approach? I suspect this > > > > isn't what we want to do, since the code size of this stub isn't > > > > small, but I just wanted to get it working, so that optimization > > > > doesn't throttle back for the whole function if an integer mod is > > > > seen. Secondly, any ideas on what I'm missing or doing incorrectly? > > > > Thanks a lot. > > > > > > - Shasank > > > > > > -- > > > > v8-users mailing list > > > > [email protected] > > > >http://groups.google.com/group/v8-users > > > > > -- > > > v8-users mailing list > > > [email protected] > > >http://groups.google.com/group/v8-users > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
