string methods intrinsics, place for checks

[Tom Rodriguez]

I think the boundaries you do look fine and the code looks good.  I  
think the argument order for StrComp and StrIndexOf should be based on  
the pairs, s1 c2 s2 c2, instead of pointers then counts.  Otherwise it  
looks good.

Any chance the x86 assembly could be moved out of the ad file into the  
shared part of assembler_x86?  The code is almost exactly the same at  
least for StringEquals and StrComp and the differences could be  
papered over easily.  Having one copy seems better.

tom

On Aug 18, 2009, at 7:15 PM, Vladimir Kozlov wrote:

> Tom Rodriguez wrote:
>> If you mean constant folding the loads of the final fields of a  
>> Constant string, I've got some changes for that coming.
>
> Yes, I meant that.
>
> And here is the first draft for string intrinsics changes:
>
> http://cr.openjdk.java.net/~kvn/6827605/webrev.00
>
> Vladimir
>
>> tom
>> On Aug 18, 2009, at 4:10 PM, Vladimir Kozlov wrote:
>>> I will send first draft tomorrow so you will see.
>>>
>>> An other question: should I add the check for argument->is_Con()
>>> (string constant) and load argument's parameters statically
>>> (as we do in indexOf intrinsic on not SSE42 path)?
>>>
>>> Or should I add the ideal optimization?
>>>
>>> Currently ideal optimizations do not convert loadI(AddP(ConP, 28))
>>> to static load.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> I don't know that there's a clear place to draw the line.  I'd  
>>>> tend towards writing things in ideal if possible since that  
>>>> exposes it to optimization and reduces the amount of assembly.   
>>>> I'd probably have a stronger opinion about a more concrete example.
>>>> tom
>>>> On Aug 18, 2009, at 2:35 PM, Vladimir Kozlov wrote:
>>>>> I am modifying our string intrinsics to pass char[] pointers and
>>>>> counters instead of string oops to allow EA eliminate non-escaping
>>>>> string object (6827605). This will also allow to do some checks
>>>>> in ideal graph instead of in a mach node encoding. But it may  
>>>>> affect
>>>>> ideal optimizations since it may complicate control flow.
>>>>>
>>>>> So I need your opinion where I should draw the line.
>>>>>
>>>>> For example, for String.equals() I compare counters in ideal but
>>>>> check it for 0 in mach (mach node needs only one counter) since
>>>>> == 0 is rare case.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>>