United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6469339 : wrong format strings for register operands hide real register usage

Details
Type:
Bug
Submit Date:
2006-09-11
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2007-01-17
Component:
hotspot
OS:
linux_suse_sles_9
Sub-Component:
compiler
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
hs10 (b06)

Related Reports
Backport:
Backport:

Sub Tasks

Description
In .ad file, the format 
operand no_rax_RegL()
%{
  constraint(ALLOC_IN_RC(long_no_rax_rdx_reg));
  match(RegL);
  match(rRegL);
  match(rdxRegL);

  format %{ "RCX" %}
  interface(REG_INTER);
%}
If register selected other than RCX the output of PrintOptoAssembly will be wrong. The output will be confusing since the real case with no rcx selected.

                                    

Comments
SUGGESTED FIX

Webrev:                 http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2006/20061219175017.never.6469339/workspace/webrevs/webrev-2006.12.19/index.html

Fixed 6469339: wrong format strings for register operands hide real
               register usage

There were some register operand definitions in amd64.ad that had
fixed format strings even though they could be assigned to multiple
registers, which could result in misleading PrintOptoAssembly output.
In addition to fixing the format string I added code to check that
only operands with bound registers can have fixed format strings and
issue an error if that's no the case.

This webrev also includes a bunch of new sanity checks and warning
messages for things which don't work or don't do what you think.
Several syntax errors which used to cause a SEGV now report real error
messages.  Line numbers are being recorded and reported more
consistently in the error messages as well.

I also deleted some dead code and used const more consistently.  Some
changes were made to remove declarations that hid latent bugs, turning
certain kinds of errors into compile time errors instead of runtime
errors.

It's now possible to refer to operands which are KILLs in format
strings and encodings by using their $ name.  That used to cause a
SEGV or assertion failure.  I've fixed all the places in the ad files
where this was being worked around.

One broader ad change is that I've removed all the KILLs of the box
inputs to the FastLock and FastUnlock.  Almost all of these were wrong
because they attempted to kill real inputs with wide masks which
doesn't do anything.  It's now an error to KILL an operand which isn't
a bound register.  The input is a different node than the kill
projection so you can't force a kill of the same register as the
input.  The best case is that it happens to kill the same register and
the worst case is that it kills a register that no one is using which
just screws up copy elimination.  You may ask how does this code work
if the KILLs are ineffective?  It's because the Box gets cloned to
each of it's uses so the register must go dead after it's use.

I also changed some USE_KILLs to KILLs since USE implies that it's a
real input but KILLs are really normal inputs.  This should be an
error but we're abusing this at the moment to get around other
problems so I'm going to leave that for later.

A while back I changed adlc to compile with -g so that if it crashes
we can always look at the core file in hopes this would make it easier
to figure out what went wrong.  These changes should make that occur
less often but if it happen let me know.  You can just send me the
modified ad file and I can work out what went wrong.

Before and after versions of the output of adlc for all architectures
is available in
/net/smite.sfbay/export/ws/adregs/output/{before,after} if you are
interested in what gets generated.

http://javaweb.sfbay/~never/webrev/6469339

Reviewed by: jrose, kvn

Fix verified (y/n): y
   refworkload
                                     
2006-12-20
EVALUATION

We can detect and complain about some version of this problem but I think it would be better if formats were never specified for register operands.
                                     
2006-09-11



Hardware and Software, Engineered to Work Together