Re: Assembling span-dependent instructions

Kaz Kylheku <>
Fri, 29 Jul 2022 22:36:03 -0000 (UTC)

          From comp.compilers

Related articles
Assembling span-dependent instructions (2022-07-27)
Re: Assembling span-dependent instructions (Kaz Kylheku) (2022-07-27)
Re: Assembling span-dependent instructions (2022-07-28)
Re: Assembling span-dependent instructions (2022-07-28)
Re: Assembling span-dependent instructions (gah4) (2022-07-29)
Re: Assembling span-dependent instructions (Kaz Kylheku) (2022-07-29)
| List of all articles for this month |

From: Kaz Kylheku <>
Newsgroups: comp.compilers,comp.arch
Followup-To: comp.compilers
Date: Fri, 29 Jul 2022 22:36:03 -0000 (UTC)
Organization: A noiseless patient Spider
References: 22-07-049 22-07-052 22-07-055
Injection-Info:; posting-host=""; logging-data="48733"; mail-complaints-to=""
Keywords: code, optimize
Posted-Date: 29 Jul 2022 19:01:02 EDT

["Followup-To:" header set to comp.compilers.]
On 2022-07-28, <> wrote:
> In comp.arch Kaz Kylheku <> wrote:
>> On 2022-07-27, Anton Ertl <> wrote:
>> > However, one can also construct cases where making the code larger can
>> > reduce the minimum size of the immediate operand, e.g.:
>> >
>> > foo:
>> > movl foo+133-bar(%rdi),%eax
>> > bar:
>> That's weird; what is accessed this way, relative to the code,
>> and does it occur in compiler output?
> Code like this may appear due to alignment, say jump to page or cache
> line boundary. In realistic situation one is faced in much more
> compilex problem. Namely on many architectures best way to provide
> constant arguments is by storing constants in memory. This leads to
> "constant pools" and problem where to place them. One wants constant
> pools as close as possible to code, to use short offsets accessing
> them. But for performance reasons it is desirable to put constants in
> separate cache lines. Also, one needs jumps to jump around constant
> pools. Some jumps occur naturally in program, it is good to re-use
> them. But there are possible unused parts of cache lines (both for
> code and constant pools). So there is need to balance loss due to
> unused parts of cache lines (probably dominant factor), length of
> instructions and possible overhead due to extra instructions.

OK; so that makes sense. Say we have a program segment with
some PC relative references to a cache-aligned constant pool
which is farther down the program.

If this program segment shrinks, while the cache-aligned
constant pool stays where it is (to remain aligned),
then that pool will be farther away from some of those

This could even happen due to smaller alignments like 8 bytes.
Some instruction loses 4 bytes; then another one experiences
the data being 4 bytes farther than before, which now
doesn't fit.

> There is extra complication when machine has limited range of offsets
> which can be used in single intstruction: when needed offset exceeds
> allowed range one has to change to indirect form which needs free
> register. So there is extra interaction with registes allocation.

On an architecture that is not so register starved, you just
dedicate a register for that. MIPS calls it "at" ("assembler temporary").

TXR Programming Language:
Cygnal: Cygwin Native Application Library:

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.