[LLVMbugs] [Bug 19348] New: DAGCombiner does not check for legal ExtLoad operation before folding (aext (zextload x)) -> (aext (truncate (*extload x)))

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19348

            Bug ID: 19348
           Summary: DAGCombiner does not check for legal ExtLoad operation
                    before folding (aext (zextload x)) -> (aext (truncate
                    (*extload x)))
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: stanislav.mekhanoshin at amd.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Our custom BE does not support extloads from i8 and i16 right into i64, but
there are no legal i8 and i16 types either, only i32 and i64 are legal. So we
have custom lowering for such loads which does extload from a sub-dword type to
i32 register and then generates extension from i32 to i64. This is the only way
the HW can do this is fact.

The DAGCombiner detects double extension and folds it back to a single
extending load from a sub-dword to i64, which is marked by BE as custom, not
legal. This results in "cannot select" error. Custom lowering is not called
anymore after the legalization (if it does that would incur an endless loop, I
suppose).

The working solution is to check in DAGCombiner if a requested ext load
operation is legal and do not perform optimization if it is not.

Both zext and sext cases are guarded with such check, but not aext.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140404/ff5ed3e9/attachment.html>