JDK-6469339 : wrong format strings for register operands hide real register usage
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_suse_sles_9
  • CPU: x86
  • Submitted: 2006-09-11
  • Updated: 2010-04-02
  • Resolved: 2007-01-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
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
20-12-2006
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.
11-09-2006