From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2560 invoked by alias); 15 Apr 2009 16:55:12 -0000 Received: (qmail 2545 invoked by uid 22791); 15 Apr 2009 16:55:10 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33,J_CHICKENPOX_38,J_CHICKENPOX_42 X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Apr 2009 16:55:04 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZEmTjTVav7/dnIJ5weE= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.34] (hightec-gate.internett.de [82.192.203.42]) by post.strato.de (klopstock mo3) (RZmta 18.28) with ESMTP id g04d34l3FG7DvU ; Wed, 15 Apr 2009 18:55:00 +0200 (MEST) Message-ID: <49E62055.1020007@gjlay.de> Date: Wed, 15 Apr 2009 16:55:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ian Lance Taylor CC: gcc-help@gcc.gnu.org Subject: Re: Reload pass ignores constraints. Why? References: <49E4673B.10903@gjlay.de> <49E4E0E2.9090401@gjlay.de> <49E5DB32.2020905@gjlay.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00181.txt.bz2 Ian Lance Taylor schrieb: > Georg-Johann Lay writes: > >>> that--if LEGITIMATE_CONSTANT_P accepts 0xffffff--then you need to ensure >>> that your movsi insn will handle 0xffffff directly, without using any >>> pseudo-registers when can_create_pseudo_p returns false. >> That works, of course. But I must admit that I prefer to express what >> is going on in terms of algebra, i.e. in terms of RTL instead of >> acting as if the core could handle the constant and just printng out >> some asm sequencs. movsi expands constants that cannot be loaded in >> one machine instruction to a movesi_insn and an arithmetic insn, and >> movsi_insn therefore allows only constants that are easy to load. > > You shouldn't print out some asm sequence, you should make movsi a > define_expand which emits a sequence of insns which do not require new > pseudo-registers. See, e.g., mips_move_integer which is called > (indirectly) by the mov define_expand in mips.md. Up to now, I see the following stategies: i) Expand to a single insn that matched by *movsi_insn: Bad, because not optimal and the insn output will print several asm statements en bloc (the movsi expander does not print anything, of course) ii) Expand into MOV+LSHIFTRT and deny the resulting const in *movsi_insn predicate and condition: Bad, because it crashes reload (as we saw above) iii) Expand into MOV+LSHIFTRT and allow the resulting const in *movsi_insn: CSE et. al. will reconstruct the original constant and replace MOV+LSHIFTRT with a single SET: Bad: expanding was in vain and we Goto i) iv) Expand into MOV+LSHIFTRT and remove the const from LEGITIMATE_CONSTANT_P: Bad, because constant will end up in constant pool. v) Expand into MOV+ADD sequence. Works(?), but Bad: Code bloat of 100% compared to optimum. Ok, I could catch it in a peep2... The difference is that in contrast to lshiftrt the add can handle the required addition without need of reloads. vi) Expand into MOV+LSHIFTRT and allow the constand only if reload_in_progress||reload_completed: Bad: runs into ICE I didn't follow this path any further. Looks too hacky. The movMM expa > >> What I do not understand is that a MOV/ADD sequence (which covers >> large constants) works on RTL level, whereas MOV/SHIFTRT (which is >> more efficient in some cases) shreds global alloc. Other strategies >> could be MOV/[AND|IOR|XOR|BSWAP...] which won't work either, though. > > I don't know exactly what is going on. But it is most likely just a > coincidence that it is failing when using SHIFTRT. There is probably > some way to make it fail in other ways as well. Would state it like this: If the movMM expander expands the move into several insns, each insn must be able to handle an alternative (which reload might select) without needing a reload. Georg-Johann