opto: How to use MachConstantBase with Call nodes -- needed for ppc port

[Vladimir Kozlov]

Goetz,

Yes, it would be nice to avoid graph walk.

Can you extend what we already do for safepoints on sparc?:

void Parse::add_safepoint() {
   // See if we can avoid this safepoint.  No need for a SafePoint 
immediately
   // after a Call (except Leaf Call) or another SafePoint.
   Node *proj = control();
   bool add_poll_param = SafePointNode::needs_polling_address_input();
   uint parms = add_poll_param ? TypeFunc::Parms+1 : TypeFunc::Parms;

It looks like we handle similar situation with simple Safepoint node 
adding an edge before debug info as you suggested but it will be normal 
ideal graph edge with input Con node.

I am fine if you do it in C2 code directly (but with a lot of testing) 
because on our platforms we will not use it.

Regards,
Vladimir

On 10/7/13 2:54 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> This is part of the ppc port, but I would like some advice before I open a
> bug and prepare a webrev.
>
> The next change I would like to prepare will be based on this patch:
> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0114_opto-hook_to_postprocess_matcher_output_platform_dependent.patch
> The method introduced there is later filled with code on ppc:
> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/compile_ppc.cpp
>
> This introduces a walk over the IR after matching, before gcm. In that walk
> we add MachConstantBaseNode to the call nodes (CallDynamicJava, CallLeaf and
> CallLeafNoFP).
> There are two problems why we need this:
>
> -          The functionality to automatically generate an input of MachConstantBaseNode
> only works with subclasses of MachConstantNode.
>
> -          Call nodes can not have ordinary operands with ins.
>
> We decided to implement this additional walk over the IR because it was the solution
> with the least change to shared code.
>
> Actually I would prefer a solution that gets along without this walk.
> This would be possible by adding support for ordinary ins/operands in Call nodes.
> The ins could be:
>    [[The 5 basic operands] [the params] [new: the ordinary ins as specified by operands] [the jvms ins] [oop_map ins]]
>
> oper_input_base() would have to return something like 'TypeFunc::Parms + tf()->_domain->_cnt',
> and we would have to add oper_input_end() which does a loop over the opers
> and counts the ins required:
>    oper_input_end() {
>     int end = oper_input_base()
>     for (uint i = 1; i < num_opnds(); ++i) {  end += _opnds[i]->num_edges();  }
>     return end;
>    }
> Also, jvms->locoff() etc would have to depend on oper_input_end() in some way.
>
> Alternatively, one could put the ordinary ins behind jvms, then
> oper_input_base() would have to return jvms->endoff(),
> and oop_maps would have to use oper_input_end() to locate their first in.
>
> Further, I would have to add a new MachOperand that represents the
> ConstantBase
>
> What do you think?  Would you rather prefer the existing solution,
> or should I try to implement what I described?  Do you have a better
> idea how to add the ConstantBase to Calls?
>
> Best regards,
>    Goetz.
>