Change to calling conventions for aggregate (e.g. struct) parameters

[Alex Bradbury]

Hi all,

As you may know, there has been an effort to document details of the
RISC-V PSABI at https://github.com/riscv/riscv-elf-psabi-doc. The
calling convention described there differs from that in the 2.1 user
spec in a number of ways. I was curious what the reasoning was for
going from passing as much of an aggregate as will fit in arg
registers, vs passing structs <=2*xlen in arg registers?

Thanks!

Alex

[Alex Bradbury]

Sorry, that was my mistake - that aspect didn't change. 2.1 does say
"Arguments more than twice the size of a pointer-word are passed by
reference." I retract my question.

Best,

Alex

[Vania Joloboff]

With the compressed instructions, instructions somehow become variable
size.
It is impossible to predict the size of the next instruction.
As a 64 bit quantity can be interpreted possibly as 1 or 2 instructions,
it seems to mean the disambiguation may come only from the low order bits
of the 64 bits. If they are not 11, then there are 2 compressed
instructions.
Consequently, there may never be an odd number of
compressed instructions between two uncompressed instructions.
Is this a valid axiom ?

Also, it seems there is a documentation error in the compressed
instructions chapter (version 2.1)
The instructions C.MV and C.ADD are listed (page 87) to have encoding C0
but they appear later in table 14.6 (page 92) for encoding C2.
It seems C2 is the real encoding and page 87 is wrong.


--
Best Regards,

Vania Joloboff
INRIA Bretagne Atlantique
Campus de Beaulieu
35042 Rennes Cedex
Tél: +33 (0)2 9984 7100
Fax: +33 (0)2 9984 7171

[Andrew Waterman]

On Fri, Mar 10, 2017 at 12:02 AM, Vania Joloboff
<vania.j...@inria.fr> wrote:
> With the compressed instructions, instructions somehow become variable size.
> It is impossible to predict the size of the next instruction.
> As a 64 bit quantity can be interpreted possibly as 1 or 2 instructions,
> it seems to mean the disambiguation may come only from the low order bits
> of the 64 bits. If they are not 11, then there are 2 compressed
> instructions.
> Consequently, there may never be an odd number of
> compressed instructions between two uncompressed instructions.
> Is this a valid axiom ?

4-byte instructions may begin on any 2-byte boundary when the
Compressed extension is present, so odd-length sequences of 2-byte
instructions are legal.

>
> Also, it seems there is a documentation error in the compressed
> instructions chapter (version 2.1)
> The instructions C.MV and C.ADD are listed (page 87) to have encoding C0
> but they appear later in table 14.6 (page 92) for encoding C2.
> It seems C2 is the real encoding and page 87 is wrong.

Thanks for pointing out this documentation error. It'll be fixed in
the next draft. (It looks like C.EBREAK was also described
incorrectly; all should be C2.)

>
>
> --
> Best Regards,
>
> Vania Joloboff
> INRIA Bretagne Atlantique
> Campus de Beaulieu
> 35042 Rennes Cedex
> Tél: +33 (0)2 9984 7100
> Fax: +33 (0)2 9984 7171
>

> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/4cabe62a-415c-d5a5-aa33-6a0c013edcb8%40inria.fr.

[Vania Joloboff]

On 03/10/2017 09:18 AM, Andrew Waterman wrote:
> On Fri, Mar 10, 2017 at 12:02 AM, Vania Joloboff
> <vania.j...@inria.fr> wrote:
>> With the compressed instructions, instructions somehow become variable size.
>> It is impossible to predict the size of the next instruction.
>> As a 64 bit quantity can be interpreted possibly as 1 or 2 instructions,
>> it seems to mean the disambiguation may come only from the low order bits
>> of the 64 bits. If they are not 11, then there are 2 compressed
>> instructions.
>> Consequently, there may never be an odd number of
>> compressed instructions between two uncompressed instructions.
>> Is this a valid axiom ?
> 4-byte instructions may begin on any 2-byte boundary when the
> Compressed extension is present, so odd-length sequences of 2-byte
> instructions are legal.

Then I am not sure to understand how the decoder is decidable.
After decoding an instruction (whether 2 or 4 bytes)
there are two possibilities that are a priori undistinguishable,
unless the decoder always checks for '11' low bits on the next 4 bytes,
whatever is the current instruction ?

[Vania Joloboff]

Forget my questions.
I was confused with big endian thinking.

[Sean Halle]

On Friday, March 10, 2017 at 12:19:09 AM UTC-8, andrew wrote:

4-byte instructions may begin on any 2-byte boundary when the
Compressed extension is present, so odd-length sequences of 2-byte
instructions are legal.

Hi Andrew, resurrecting this old thread..  we're doing hardware that receives a significant penalty when a 32bit instruction is divided between two cache lines.  Has this issue been raised by others?  

A simple fix is to add a compiler switch to pad odd length sequences of compressed instructions, forcing natural alignment -- 16bit instructions aligned on 16bit boundaries, and 32bit aligned on 32bit boundaries.  Then every instruction is contained wholly within a single cache line.  We currently have disabled compressed instruction support, until we can modify the compiler ourselves.  What would be the chances of such a switch becoming official?  In a stretch, what do you see as the chances for a modification to the spec, to provide a variant where instructions are aligned to their natural boundaries?

Thanks :-)

[Bruce Hoult]

Hmm .. it seems like a bit of a hammer to crack a walnut. I think you'd get significant code expansion if you insisted that every 32 bit instruction is 32 bit aligned. It would be much less of a problem if you only did it on the actual cache line crossings -- which you can know about if you align functions to cache lines.

In either case, it doesn't seem like something for the ISA spec, but rather just a compiler code generation tuning switch.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/da67cfd7-4b47-4048-a6fb-488195ed3c2d%40groups.riscv.org.

[Jim Wilson]

On Sat, May 12, 2018 at 5:28 PM, Sean Halle <sean...@gmail.com> wrote:
> A simple fix is to add a compiler switch to pad odd length sequences of
> compressed instructions, forcing natural alignment -- 16bit instructions
> aligned on 16bit boundaries, and 32bit aligned on 32bit boundaries. Then
> every instruction is contained wholly within a single cache line. We
> currently have disabled compressed instruction support, until we can modify
> the compiler ourselves. What would be the chances of such a switch becoming
> official? In a stretch, what do you see as the chances for a modification
> to the spec, to provide a variant where instructions are aligned to their
> natural boundaries?

GCC or LLVM? The answers are different.

For gcc, you need an FSF copyright assignment if you want to
contribute a patch. Depending on your employer, this may be easy or
difficult to get. The standard FSF copyright assignment has language
about patent rights, and some company lawyers are uncomfortable with
that. Otherwise, adding an option is usually not too hard. If it
does something useful, and is reasonably clean, it will likely be
accepted.

The actual implementation may be a problem though. GCC currently
doesn't know anything about compressed instructions. This is
something we would eventually like to fix. Meanwhile, it is the
assembler that decides if an instruction can be 2 or 4 bytes. And
then the linker does relaxation optimizations that can compress
additional instructions at link time. So it isn't until link time
that you know which instructions are compressed and which aren't.
That is too late to align instructions. The linker can reduce code
size, but it can't increase code size, so we can't easily add
alignment nops at link time. If you turn off linker relaxation, which
will disable some optimizations, and modify the assembler to insert
alignment nops before every assembly-time 4 byte instruction, then you
should get the right result. It may take some experimentation to get
a patch that works. Depending on how much effort you want to put into
this, you could optimize this a few ways. You don't need to disable
all linker relaxations, just the ones that create compressed
instructions. As Bruce mentioned if you align code to the cache size
boundary, you can probably detect exactly when a padding nop is needed
before a cache line boundary, but if you haven't disabled all linker
relaxation, then you would need to do that in the linker, and that
would require a new relocation emitted by the assembler. If you
disable all linker relaxation, then you could do this in the assembler
and wouldn't need a new relocation.

Jim

[Bruce Hoult]

An interesting question is "How often does this happen?"

The answer depends on the percentage of compressed instructions. Obviously it never happens if there are no compressed instructions, or 100% of compressed instructions.

It turns out that if p is the probability of each instruction being *not* compressed, and assuming instructions are independent, then for p less than about 0.8 the probability of the last instruction in a cache line crossing into the next cache line is almost exactly p/(1+p). e.g. for various ratios of uncompressed:compressed...

80:20 0.444 (4/9)

75:25 0.429 (3/7)

60:40 0.375 (3/8)

50:50 0.333 (1/3)

40:60 0.286 (2/7)

25:75 0.200 (1/5)

20:80 0.167 (1/6)

10:90 0.091 (1/11)

This relationship is more exact the longer the cache line, but is already correct to 2DP for 16 byte cache lines and at least 40% compressed instructions.

We're normally seeing around 50% - 60% of compressed instructions (40% - 50% not compressed), so we'll see 4 byte instructions crossing a cache line about 28% - 33% of the time -- or about once in 40 - 50 instructions executed for 32 byte cache lines.

You have to ask, just how bad is this penalty? It would have to be pretty bad to be worth doing something about.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/da67cfd7-4b47-4048-a6fb-488195ed3c2d%40groups.riscv.org.

[Andrew Waterman]

That ISA change won’t become standardized, but it’s reasonable for compilers to optimize for this case. I imagine the GCC maintainers would be willing to consider a patch to add this feature. Note that linker relaxations will make this challenging (and disabling linker relaxations will result in a large code-size hit itself). Optimizing the microarchitecture instead may well be simpler.

Thanks :-)

-- 

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/da67cfd7-4b47-4048-a6fb-488195ed3c2d%40groups.riscv.org.

[Luke Kenneth Casson Leighton]

Apologies using phone peck, what about 48b instructions, should those be padded, also when misa disabled, 48b directly after, what happens?

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/da67cfd7-4b47-4048-a6fb-488195ed3c2d%40groups.riscv.org.

--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[Michael Clark]

> On 13/05/2018, at 7:07 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
>
> Apologies using phone peck, what about 48b instructions, should those be padded, also when misa disabled, 48b directly after, what happens?

It’s likely if not almost certain that if 48-bit instructions are supported then 16-bit will be too however 48-bit mixed with just 32-bit instructions requires that the 32-bit instructions can be 16-bit aligned. Otherwise padding them would essentially be the same as having 32-bit instructions and (inefficiently packed) 64-bit instructions.

BTW While we’re on this topic. I think we should add the 48-bit instructions for synthesising 32-bit constants that have been discussed several times as well as adding PC-Relative versions that can synthesise a 64-bit value that is within +/- 2GiB of the program counter. Perhaps they could be considered as candidate instructions for the B extension. The obvious names would be:

- LLI rd, simm32 (Load Large Immediate) 48-bit instruction to synthesise a signed 32-bit constant
- ALIPC rd, simm32 (Add Large Immediate to Program Counter) 48-bit instruction to synthesise a 64-bit constant within +/- 2GiB of the program counter

We could then use ALIPC+C.JALR to encode a long jump (+/-2GiB) in 64-bits (48-bit ALIPC + 16-bit C.JALR).

These would be useful for a compiler test bed for a testing a decoder that handles 16/32/48-bit instructions…

[Bruce Hoult]

While that is perhaps[1] a reasonable use of 1/32 of the 48 bit opcode space (if I counted my bits correctly), I think it would be an unreasonable burden to force anyone implementing the bit manipulation extension to support decoding 48 bit instructions -- especially if they don't support C!

[1] I'm not sure that 32 bit literals occur often enough that using 48 bits of instruction to load them instead of 64 is a huge saving. Especially when C.LUI already lets you load arbitrary 18 bit literals (+/- 128k) with 48 bits of instruction.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/8E91E25B-1045-4C01-8885-C878F1405825%40mac.com.

[Michael Clark]

> On 14/05/2018, at 12:35 PM, Bruce Hoult <br...@hoult.org> wrote:
>
> While that is perhaps[1] a reasonable use of 1/32 of the 48 bit opcode space (if I counted my bits correctly), I think it would be an unreasonable burden to force anyone implementing the bit manipulation extension to support decoding 48 bit instructions — especially if they don't support C!

Of course it would need to be optional. e.g. B_large_imm. The question is what extension is the logical extension for it to be a sub-extension of. Perhaps I_large_imm?

It has already been discussed that some extensions may have optional instructions and I had never intimated that a 48-bit large immediate instruction should be mandatory. There needs to be a parent extension. Perhaps an optional I_large_imm extension is more appropriate.

This was in the context of adding some form of READID instruction that expands “read-only” CSR space from 256 to XLEN. The CSR space is effectively 256 entries assuming aliases are reserved for other modes and protection bits are allowed to change as has happened in the past. i.e. this post

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/InzQ1wr_3Ak/CavmeZcnAAAJ

RDID could be an alias for CSR rd, ID, rs1; where this instruction deviates from the normal CSR semantics and carries a dependency from rs1 to rd. One entry in the CSR space could provide access to a sparse XLEN wide address space, and we could start by adding 26 words, one per extension to provide information on sub-extensions e.g.

I
E
M
M_NDIV # no div,divu,rem,remu for rv32/rv64/rv128 and no divw,divuw,remw,remuw for rv64/rv128, and no divd,divud,remd,remud for rv128
A
A_TSO # indicates implementation of total store order (RVTSO)
A_DWLRSC # double word lr/sc
F
F_NDIV # no fdiv.s
F_NSQRT # no fsqrt.s
F_INVSQRT # fast inverse square root: finvsqrt.s
F_TD # fast transcendentals: fsin.s, fcos.s
D
D_NDIV # no fdiv.d
D_NSQRT # no fsqrt.d
D_INVSQRT # fast inverse square root: finvsqrt.d
D_TD # fast transcendentals: fsin.d, fcos.d
Q
Q_NDIV # no fdiv.q
Q_NSQRT # no fsqrt.q
C
C_DICTV2 # Version 2 of RVC dictionary
L
B
B_EXTDEP # Optional bit gather scatter
J
T
P
V
V_BEXTDEP # Optional vector bit gather scatter
N
S
S_SV32 # safer for S-mode code than probing, as S-mode can’t change VM without side-effects
S_SV39
S_SV48
S_SV56
U
H
H_T1 # reserved for type 1 hypervisors that have an H-mode
H_T2 # type 2 hypervisors e.g. HS mode

> [1] I'm not sure that 32 bit literals occur often enough that using 48 bits of instruction to load them instead of 64 is a huge saving. Especially when C.LUI already lets you load arbitrary 18 bit literals (+/- 128k) with 48 bits of instruction.

Of course a 48-bit instruction to load a 32-bit immediate will result in some amount of savings. We’d have to do some analysis to figure out exactly how much. LUI+ADDI is quite frequent from eye-balling binaries.

BTW - did you see this?

- https://gcc.gnu.org/ml/gcc/2018-05/msg00012.html

> On Mon, May 14, 2018 at 11:54 AM, Michael Clark <michae...@mac.com> wrote:
>
>
> > On 13/05/2018, at 7:07 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
> >
> > Apologies using phone peck, what about 48b instructions, should those be padded, also when misa disabled, 48b directly after, what happens?
>
> It’s likely if not almost certain that if 48-bit instructions are supported then 16-bit will be too however 48-bit mixed with just 32-bit instructions requires that the 32-bit instructions can be 16-bit aligned. Otherwise padding them would essentially be the same as having 32-bit instructions and (inefficiently packed) 64-bit instructions.
>
> BTW While we’re on this topic. I think we should add the 48-bit instructions for synthesising 32-bit constants that have been discussed several times as well as adding PC-Relative versions that can synthesise a 64-bit value that is within +/- 2GiB of the program counter. Perhaps they could be considered as candidate instructions for the B extension. The obvious names would be:
>
> - LLI rd, simm32 (Load Large Immediate) 48-bit instruction to synthesise a signed 32-bit constant
> - ALIPC rd, simm32 (Add Large Immediate to Program Counter) 48-bit instruction to synthesise a 64-bit constant within +/- 2GiB of the program counter
>
> We could then use ALIPC+C.JALR to encode a long jump (+/-2GiB) in 64-bits (48-bit ALIPC + 16-bit C.JALR).
>
> These would be useful for a compiler test bed for a testing a decoder that handles 16/32/48-bit instructions…
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/8E91E25B-1045-4C01-8885-C878F1405825%40mac.com.
>
>

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkz1H6vSVhnQZLL8s18ctkzDjRPvMNdTcf0BK2RpP2aEdw%40mail.gmail.com.

[Bruce Hoult]

On Mon, May 14, 2018 at 1:08 PM, Michael Clark <michae...@mac.com> wrote:

BTW - did you see this?

- https://gcc.gnu.org/ml/gcc/2018-05/msg00012.html

​I hadn't seen it. Interesting.

I see they claim 20% denser code than previous MIPS, but only 10% denser compared to competitors (presumably Thumb2).​

I didn't find the detailed instruction set, but it sounds as if a number of instructions are going to expand to multiple uops (or hardware sequencing).

[Gnanasekar R]

Interesting.. am also interested to know if there are any special code density optimization options in gcc for riscv-target.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkzpHDqGFO2hcFuraksMEFFdnAQn%2B3hCs%3Dx4e34%3DbGYwtw%40mail.gmail.com.

[Bruce Hoult]

Only a static order of register allocation at the moment. Much work could be done given the manpower and no higher priorities.

On Mon, May 14, 2018 at 5:21 PM, Gnanasekar R <gnanase...@gmail.com> wrote:

Interesting.. am also interested to know if there are any special code density optimization options in gcc for riscv-target.

On 14 May 2018 at 06:55, Bruce Hoult <br...@hoult.org> wrote:

On Mon, May 14, 2018 at 1:08 PM, Michael Clark <michae...@mac.com> wrote:

BTW - did you see this?

- https://gcc.gnu.org/ml/gcc/2018-05/msg00012.html

​I hadn't seen it. Interesting.

I see they claim 20% denser code than previous MIPS, but only 10% denser compared to competitors (presumably Thumb2).​

I didn't find the detailed instruction set, but it sounds as if a number of instructions are going to expand to multiple uops (or hardware sequencing).

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkzpHDqGFO2hcFuraksMEFFdnAQn%2B3hCs%3Dx4e34%3DbGYwtw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CANUXKs_3ufEkQunRK5%3DOtqyBazF%3Dh_nFvn5giVjW%2BdgELTe2QA%40mail.gmail.com.

[Gnanasekar R]

Is that a separate compiler switch?

Does llvm have something similar to gcc's "-msave-restore" to produce smaller prologues/epilogue code.

On 14 May 2018 at 11:33, Bruce Hoult <br...@hoult.org> wrote:

Only a static order of register allocation at the moment. Much work could be done given the manpower and no higher priorities.

On Mon, May 14, 2018 at 5:21 PM, Gnanasekar R <gnanase...@gmail.com> wrote:

Interesting.. am also interested to know if there are any special code density optimization options in gcc for riscv-target.

On 14 May 2018 at 06:55, Bruce Hoult <br...@hoult.org> wrote:

On Mon, May 14, 2018 at 1:08 PM, Michael Clark <michae...@mac.com> wrote:

BTW - did you see this?

- https://gcc.gnu.org/ml/gcc/2018-05/msg00012.html

​I hadn't seen it. Interesting.

I see they claim 20% denser code than previous MIPS, but only 10% denser compared to competitors (presumably Thumb2).​

I didn't find the detailed instruction set, but it sounds as if a number of instructions are going to expand to multiple uops (or hardware sequencing).

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkzpHDqGFO2hcFuraksMEFFdnAQn%2B3hCs%3Dx4e34%3DbGYwtw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CANUXKs_3ufEkQunRK5%3DOtqyBazF%3Dh_nFvn5giVjW%2BdgELTe2QA%40mail.gmail.com.

[Alex Bradbury]

On 14 May 2018 at 09:40, Gnanasekar R <gnanase...@gmail.com> wrote:
> Is that a separate compiler switch?
>
> Does llvm have something similar to gcc's "-msave-restore" to produce
> smaller prologues/epilogue code.

Not currently.

Best,

Alex