PTAL @dotnet/jit-contrib

@dotnet-bot test tizen armel Cross Debug Build

@sandreenko it seems odd that we are seeing an address tree of the form that you've described, especially if this occurs only on CoreRT. Are we sure that the base should be a compile-time constant that isn't a relocatable handle (which would not be constant-foldable)?

It is not connected with CoreRT, it is RyuJit x86 problem.
@BruceForstall we need your opinion about this PR.
Possible solutions are:

1. forbid addr modes without registers, return false in doAddrMode() if it happens and:
   1.1. do constant folding in morph( it will positively affect more code rather then addrModes) ;
   1.2 do not fold constant trees in minopts;
   1.3 do local constant folding from value numbering in minOpts (the best variant in my opinion, but it requires the separate issue).
2. allow addr modes without registers (it is the current PR), but change EdgeIterator;
3. return doAddrMode == true for this case, but check that it is actual constant and create constant instead of LEA. (I do not like this variant, it makes code less clear).

(3) is my preferred solution, as it is minimally invasive and does not change the semantics of GT_LEA (unlike option 2).

I'm a bit confused about your suggestions. For 1, are you suggesting having genCreateAddrMode() (not doAddrMode(), which isn't a function that I see) return false if the address mode it computes is purely a constant? That would be my preference. I don't see the need to change any constant folding, in minopts. The comment for genCreateAddrMode() already says it doesn't handle pure [icon] addressing modes, but it didn't expect to see an add that creates such a thing. Changing it to return false in this case seems to strengthen its existing contract.

@dotnet-bot test OSX10.12 x64 Checked Build and Test (network)

PR was updated. Please look again.