On Sat, Jun 15, 2024 at 1:22 AM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 6/14/24 11:10 AM, Alexander Monakov wrote: > > > > On Fri, 14 Jun 2024, Kong, Lingling wrote: > > > >> APX CFCMOV[1] feature implements conditionally faulting which means that > >> all memory faults are suppressed > >> when the condition code evaluates to false and load or store a memory > >> operand. Now we could load or store a > >> memory operand may trap or fault for conditional move. > >> > >> In middle-end, now we don't support a conditional move if we knew that a > >> load > >> from A or B could trap or fault. > > > > Predicated loads&stores on Itanium don't trap either. They are modeled via > > COND_EXEC on RTL. The late if-conversion pass (the instance that runs after > > reload) is capable of introducing them. > > > >> To enable CFCMOV, we add a target HOOK > >> TARGET_HAVE_CONDITIONAL_MOVE_MEM_NOTRAP > >> in if-conversion pass to allow convert to cmov. > > > > Considering the above, is the new hook really necessary? Can you model the > > new > > instructions via (cond_exec () (set ...)) instead of (set (if_then_else > > ...)) ? > Note that turning on cond_exec will turn off some of the cmove support. Yes, cfcmov looks more like a cmov than a cond_exec. > > But the general suggesting of trying to avoid a hook for this is a good > one. In fact, my first reaction to this thread was "do we really need a > hook for this". Maybe a new optab, .i.e cfmovmodecc, and it differs from movcc for Conditional Fault? > > jeff
-- BR, Hongtao
