Request for reviews (XXL): 6961690: load oops from constant table on SPARC

[Paul Hohensee]

It should be a check on a VM_Version method such as is_niagara.  I expect
this to be a performance loss on non-T-series sparc.

Paul

On 11/18/10 2:30 PM, Vladimir Kozlov wrote:
> Christian,
>
> I like this code better but I still think that we should have a flag
> which controls how we load constant oops and longs.
> We may do it by just adding predicate(flag) into .ad file. Could you,
> please, check? And yes, we may need to keep some code you removed.
>
> Instead of using new flag ConstantTableAbsoluteAddressing (we have more
> flags than we need already) you should use Matcher's variable like next:
>
> const bool Matcher::clone_shift_expressions = true;
>
> I don't understand how MachConstantBaseNode::size() is not called
> on sparc where there is code generated for it? You need the size.
> It seems, you have to calculate it manually.
>
> I think you don't need to add_req() in constructor and then use
> set_req(root) since new MachConstantBase node is only created in
> Compile::mach_constant_base_node() so you can add_req(root) there
>
> Thanks,
> Vladimir
>
> Christian Thalinger wrote:
>> On Nov 17, 2010, at 10:35 AM, Christian Thalinger wrote:
>>> My fault.  I was thinking that we're using RDPC when the node is not 
>>> pinned, but that's not the case.  Of course it works when not using 
>>> RDPC.
>>
>> This became a bigger change that I thought it will be.  I moved 
>> almost all logic into Compile, the constant table emission and the 
>> offset/size calculation are now two different steps which are called 
>> explicitly in Compile::Fill_buffer, and the constant table base 
>> materialization is not pinned.
>>
>> http://cr.openjdk.java.net/~twisti/6961690/webrev.02/
>>
>> -- Christian