RFR(S): 8022574: remove HaltNode code after uncommon trap calls

[Liu, Xin]

Hi, 

Could you please review this patch?
JBS: https://bugs.openjdk.java.net/browse/JDK-8022574
Webrev: https://cr.openjdk.java.net/~xliu/8022574/00/webrev/

This is the prerequisite of JDK-8230552. I agree with Martin's comment. I also want to remove the HaltNode after uncommon_trap.
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038104.html

Because the HaltNode after uncommon_trap callnode also takes a special role in Matcher::Fixup_Save_On_Entry, 
it's not easy to get rid of it.  I took another approach. I mark that HaltNode not reachable. As a result, backends can choose not to expand it. 

My assumption is that the control flow should never return from uncommon_trap because it must go to the interpreter.  HaltNode is rarely generated except this case. If this kind of HaltNode becomes dummy, we are safe to use "stop()" for the instruct "ShouldNotReachHere".  Stop() could provide more debugging information if C2 crashes due to HaltNode.  

I apply this optimization for all architectures except for SPARC.

Currently, x86 generates 4 instruction, or 20 bytes for that HaltNode.
https://bugs.openjdk.java.net/browse/JDK-8022574?focusedCommentId=14336533&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14336533 

Usually, C2 generates a lot of uncommon trap calls for a variety of reasons. This patch can generate more compact code.
Eg. I observe the codeCache usage reduced even when java executes '-version'.
./linux-x86_64-server-release/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+PrintCodeCache -version
Before: 
CodeCache: size=49152Kb used=4242Kb max_used=4478Kb free=44909Kb
After:
CodeCache: size=49152Kb used=3988Kb max_used=4474Kb free=45163Kb 

Testing: 
I ran gtest and hotspot:tier1 on x86_64/linux and aarch64/linux.  No regression was identified. 

Thanks,
--lx