On 07/24/2017 11:37 AM, Georg-Johann Lay wrote: > Andrew Stubbs schrieb: >> On 24/07/17 14:58, Georg-Johann Lay wrote: >>> Dunno if that works in all situation. For example, when the register >>> allocator is facing high register pressure and decides to spill the >>> target register, it uses the constraints of the matched insn. >> >> That would be a memory to memory move, and therefore not valid in any >> mov insn on many architectures. Are you sure that's a real thing? > > Hard to tell, it depends on many gory details... > > If the additional insn is a mov insn that only catches specific cases > by its predicates, then you have definitely a problem (more than 1 mov > insn per mode). Correct. Sadly everything will seem OK here, then one day you'll have an abort or wrong code generation in reload. Been there, done that.
> > If it has an explicit mem: then the problems are completely different. > For example, it will also match volatile MEMs even for cases when > volatile_ok is false. Though presumably you could extract the MEM out of the insn so that you could check the volatile flag. Though that's fairly gross. > > In general, it's hard to find test cases which show that something > breaks. Right. Jeff
