RFR: 8290917: x86: Memory-operand arithmetic instructions have too low costs

[Quan Anh Mai]

The pattern `AddI (LoadI mem) imm` should be matched by a load followed by an add with constant, instead, it is currently matched as a constant load followed by an add with memory. The reason is that the cost of `addI_rReg_mem` is too low, this patch fixes this by increasing the cost of this fused instruction.

Testing: Manually run the test case in the JBS and look at the compiled code.

I also do some small clean-ups in x86_64.ad:

- For some reasons, `incl(Address)` is less efficient than `addl(Address, int)` as the former results in 3 uops in the fused domain as opposed to 2 in cases of the latter (according to [uops.info](uops.info)). As a result, I propose to remove the corresponding rules.
- The `mulHiL` rules have unnecessary constraints on the input registers, these can be removed. The `no_rax_RegL` operand as a consequence can also be removed.
- The rules involving long division by a constant can be removed because it has been covered by the optimiser during idealisation.
- The pattern `SubI src imm` and the likes never match because they are converted to `AddI src -imm` by the optimiser. As a result, these rules can be removed
- The rules involving shifting the argument by 1 are covered by and exactly the same as the corresponding rules of shifting by an immediate. As a result, they can be removed.
- Some rules involving and-ing with a bit mask have unnecessary constraints on the target register.

Please kindly review, thank you very much.

-------------

Commit messages:
 - remove no_rax_RegL
 - clean up

Changes: https://git.openjdk.org/jdk/pull/9791/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9791&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290917
  Stats: 373 lines in 2 files changed: 0 ins; 340 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9791.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9791/head:pull/9791

PR: https://git.openjdk.org/jdk/pull/9791