On Thu, May 19, 2016 at 8:17 PM, Jeff Law <l...@redhat.com> wrote: > On 05/15/2016 06:45 PM, Kugan Vivekanandarajah wrote: >> >> Hi Richard, >> >> Now that stage1 is open, I would like to get the type promotion passes >> reviewed again. I have tested the patches on aarch64, x86-64, and >> ppc64le without any new execution failures. There some test-cases that >> fails for patterns. I will address them after getting feedback on the >> basic structure. > > I find myself wondering if this will eliminate some of the cases where Kai's > type casting motion was useful. And just to be clear, that would be a good > thing. > >> >> 1. When we promote SSA as part of promote_ssa, we either promote the >> definition. Or create a copy stmt that is inserted after the stmt that >> define it. i.e, we want to promote the SSA and reflect the promotion >> on all the uses (we promote in place). We do this because, we don’t >> want to change all the uses. >> >> +/* Promote definition DEF to promoted type. If the stmt that defines def >> + is def_stmt, make the type of def promoted type. If the stmt is such >> + that, result of the def_stmt cannot be of promoted type, create a >> new_def >> + of the original_type and make the def_stmt assign its value to newdef. >> + Then, create a NOP_EXPR to convert new_def to def of promoted type. >> + >> + For example, for stmt with original_type char and promoted_type int: >> + char _1 = mem; >> + becomes: >> + char _2 = mem; >> + int _1 = (int)_2; > > When does this case happen, and how is this any better than PRE or other > elimination/code motion algorithms in improving the generated code?
The above case mentions one - loads from memory. Another case would be vector element extracts from vNqi vectors or asm outputs. > I would hazard a guess that it could happen if you still needed the char > sized used in a small number of cases, but generally wanted to promote most > uses to int? I think we want to promote all uses to int, we only can't always combine the extension with the value-producing stmt on GIMPLE (we don't have single-stmt sign-extending loads for example). Likewise we don't allow the equivalent of (subreg:QI SI-reg) at SSA use sites and thus will generally have a trucating stmt before such uses. This makes it somewhat difficult to assert the IL is in "promoted" form and it also exposes the challenge to inhibit passes from undoing this. I guess in the end we may want to allow "promoted" types in those stmts directly, that is, have implicit conversions in the stmts so that we see void foo (char); char *p_2; int _1; _1 = *p_2; foo (_1); where on the load we'd have an implicit extension and at the call an implicit subreg. Other cases would be, say char _1, _2; _1 = _2 <<r 3; which PROMOTE_MODE targets likely cannot express in a single instruction (that's a QImode rotate). So going the "full" promotion way might require some operation lowering to target capabilities as well. So what does this mean for this pass? It means that we need to think about the immediate goal we want to fulfil - which might be to just promote things that we can fully promote, avoiding the necessity to prevent passes from undoing our work. That said - we need a set of testcases the pass should enable to being optimized better than without it (I myself see the idea of promoting on GIMPLE according to PROMOTE_MODE as good design cleanup towards pushing GIMPLE farther out). In the end I'd like us to fully promote things, go towards doing initial(?) instruction selection on GIMPLE, making a first step towards eliminating RTL (optimizations). [I'd encourage someone to try writing a "real" non-RTL backend] Richard. >> However, if the defining stmt has to be the last stmt in the basic >> block (eg, stmt that can throw), and if there is more than one normal >> edges where we use this value, we cant insert the copy in all the >> edges. Please note that the copy stmt copes the value to promoted SSA >> with the same name. >> >> Therefore I had to return false in this case for promote_ssa and fixup >> uses. I ran into this while testing ppc64le. I am sure it can happen >> in other cases. > > Right. > > Jeff
