This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: cc0 -> CCmode questions
- From: Jeff Law <law at redhat dot com>
- To: Georg-Johann Lay <gjl at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 2 Nov 2019 10:14:15 -0600
- Subject: Re: cc0 -> CCmode questions
- References: <78b73cb4-2d3f-2e71-c334-8a3cba768c55@physik.fu-berlin.de> <5DB9E51B.40909@gcc.gnu.org> <52f7f0ca-7dd2-0cf6-0b9a-e08852b7301f@linux.ibm.com> <5DBB4B51.3040101@gcc.gnu.org> <8f8eed9b-3e0f-9bd1-bd49-3f4c2a615cee@physik.fu-berlin.de> <5DBB6443.70407@gcc.gnu.org> <20191101010608.GC28442@gate.crashing.org> <5DBDA601.6080503@gcc.gnu.org>
On 11/2/19 9:51 AM, Georg-Johann Lay wrote:
> Segher Boessenkool schrieb:
>>> Btw, does GCC support clobbering registers in branches (or
>>> cbranch<mode>4 for that matter)? This requirement would come up when
>>> transitioning avr to cc_mode because cbranches would live post reload.
>>
>> Of course. You cannot have *reloads* on branches, that is all.
>>
>> Segher
>
> Does this also apply to input reloads?
>
> Suppose cbranch with constraints like
>
> "d,r"
> "n,r"
>
> for the operands to be compared, where d is a register class that
> can be compared against immediate, but registers in r can't be
> compared to n in general.
>
> For a case #2 target (only ccmode clobbers before reload), reload might
> generate an input reload for the constant in the cbranch.
>
> So this is for bidden?
This should work in the LRA world just fine. The problems are with
output reloads, not input reloads.
With an output reload on a branch you have to emit the reload at the
target(s) of the branch as well as the fallthru path (if one exists).
In theory we could do this for simple branches, but for indirects it'd
be virtually impossible.
jeff