RFR: 8284742: x86: Handle integral division overflow during parsing

[Jatin Bhateja]

On Wed, 13 Apr 2022 19:35:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @merykitty , Nice work!
>> Target specific IR generation looks interesting approach, but UDivL/UDivI are currently being generated by intrinsification route.  Thus a post parsing target lowering stage will ideally be suited. 
>> 
>> We can also take an alternative approach  to generate separate matcher rules for both the control paths by way of setting an attribute in IR node during Identity transformation.  
>> https://github.com/openjdk/jdk/pull/7572#discussion_r813918734
>
>> @jatin-bhateja Thanks a lot for your suggestions. The transformation manipulates the control flow so it should be handled during parsing since the control edge may have been lost right after that. The same goes for UDivL and UDivI intrinsic, too. I believe having target specific parsing is beneficial since we can decompose complex operations into more elemental ones, utilizing the power of the compiler more efficiently.
>> 
>> Delaying the handling till code emission time may miss the opportunities to hoist out the check and in the worst case would result in suboptimal code layout since the compiler can move the uncommon path out of the common path while the assembler can't.
> 
> Thanks I get your point, creating a control flow later may not be possible unless an explicit control projection is added to  DivI/L node during initial parsing which gets tied to its successors, and later on the IR node itself can be replaced by a control structure which converge at original control projection.  We can save redundant duplications of byte code processing and a later stage can do target lowering.

> @jatin-bhateja The div nodes themselves are constructed with control input, it is the `Ideal` method that may remove this input. Post parse transformation does not only need to replace the div node with the control structure, but also has to restructure the control flow itself, so I think it would be much more complex to do so.
> 
> Thank you very much.

Hi @merykitty , Yes, input controlling edge cannot be used independently to create a control flow, we also need to have knowledge of next control region to create a conditional graph, thus adding an explicit output control projection from DivI/L IR nodes (which only have data flow edges) during parsing will enable creation of control flow later. Generating a control flow post parsing is not new we do it during macro expansion currently.

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

PR: https://git.openjdk.java.net/jdk/pull/8206