On Jun 22, 2017, Segher Boessenkool <seg...@kernel.crashing.org> wrote:
> On Thu, Jun 22, 2017 at 03:21:01AM -0300, Alexandre Oliva wrote: >> On Jun 8, 2017, Segher Boessenkool <seg...@kernel.crashing.org> wrote: >> >> > [ I missed this patch the first time around; please cc: me to prevent this >> > ] >> >> > On Thu, May 18, 2017 at 07:25:57AM -0300, Alexandre Oliva wrote: >> >> When an insn used by combine has multiple SETs, only the non-REG_UNUSED >> >> set is used: others will end up dropped on the floor. >> >> > Sometimes, yes; not always. >> >> You mean sets to non-REGs, I suppose. I didn't take them into account >> in my statement indeed, but I think it still applies: can_combine_p will >> reject parallel SETs if two or more of them don't have a REG_UNUSED note >> for their respective SET_DESTs. > can_combine_p is not called for I3; it also isn't called until after > I2 is split, if that happens. Oh, I see what you mean now. I just don't think of I3 as "used"; other insns are "used" in that they are substituted, in whole or in part, into I3. On Jun 22, 2017, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > On Thu, Jun 22, 2017 at 09:25:21AM -0300, Alexandre Oliva wrote: >> On Jun 8, 2017, Segher Boessenkool <seg...@kernel.crashing.org> wrote: >> >> > Would it work to just have "else" instead if this "if"? Or hrm, we'll >> > need to kill the recorded reg_stat value in the last case before this >> > as well? >> >> The patch below (is this what you meant?) > Yes exactly. >> How's this? (I haven't run regression tests yet) > Looks a lot better digestable than the previous patch, thanks! > Things should probably be restructured a bit so we keep the sets count > correct, if that is possible? I'll have to think a bit to figure out the exact conditions in which to decrement the sets count, and reset the recorded value. I was thinking the conditions were the same; am I missing something? Or are you getting at cases in which we should do both and don't, or vice-versa? E.g., if reg_referenced_p holds but the subsequent test doesn't? I guess we do, but don't we have to distinguish the cases of an original unused set remaining from that of reusing the pseudo for a new set? Do we have to test whether from_insn still reg_sets_p the REG_UNUSED operand, when from_insn is not i3? (e.g., it could be something that remains set in i1 as a side effect, but that's not used in either i2 or i3) Am I overdoing this? The situations I had to analyze in the patch I posted before were much simpler, and even then I now think I missed a number of them :-) >> When an insn used by combine has multiple SETs, only the non-REG_UNUSED >> set is used: others will end up dropped on the floor. > write something simpler like > If combine drops a REG_UNUSED SET, [...] Nice, thanks. > Similar for this comment. (It has a stray tab btw, before "We"). *nod* > Maybe use "long long"? Less incorrect/misleading on 32-bit targets ;-) Sure, thanks. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
