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 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
