[llvm-dev] Risc-v Assembly printer function order

30 views
Skip to first unread message

'Irenee GROZ IG255340' via llvm-dev

unread,
Aug 7, 2018, 3:54:09 AM8/7/18
to llvm...@lists.llvm.org
Hello,

I am working on the assembly printer for RISC-V, more specifically on
the AsmPrinter class.
I altered the RISCV Backend to print C code instead of Assembly,
interpreted by libraries... (but that's not important)
My problem is that, for my application to work, I need to treat my
functions in the order they are in the original C file.
I discovered that these functions are not treated in this order.

My question is : Is there a way to force llvm to treat the functions in
the order given in the original C file ? and how?

I treat each function in the EmitFunctionBody funtion of the AsmPrinter
class, and the function is passed through the MachineFunction passed
trhough the runOnMachineFunction function. I didn't find where this last
function is called.
So I wish maybe to alter the way this function is called for each
Function to call it in the "right" order...

Thanks,
Best regards,
IG

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Friedman, Eli via llvm-dev

unread,
Aug 7, 2018, 1:58:33 PM8/7/18
to Irenee GROZ IG255340, llvm...@lists.llvm.org
On 8/7/2018 12:54 AM, 'Irenee GROZ IG255340' via llvm-dev wrote:
> Hello,
>
> I am working on the assembly printer for RISC-V, more specifically on
> the AsmPrinter class.
> I altered the RISCV Backend to print C code instead of Assembly,
> interpreted by libraries... (but that's not important)
> My problem is that, for my application to work, I need to treat my
> functions in the order they are in the original C file.
> I discovered that these functions are not treated in this order.
>
> My question is : Is there a way to force llvm to treat the functions
> in the order given in the original C file ? and how?

The LLVM backend should generally print functions in the same order they
appear in the IR.  This is an implementation detail, not a guarantee,
but there currently aren't any backend passes that rearrange functions.

That said, clang doesn't really try to emit functions in source order:
it will delay emitting functions for various reasons.  If that's truly
necessary for your use-case, you'll probably have to modify clang
somehow.  Or maybe -femit-all-decls is close enough if your input is pure C?

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

via llvm-dev

unread,
Aug 7, 2018, 3:31:18 PM8/7/18
to efri...@codeaurora.org, irene...@cea.fr, llvm...@lists.llvm.org


> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev...@lists.llvm.org] On Behalf Of
> Friedman, Eli via llvm-dev
> Sent: Tuesday, August 07, 2018 1:58 PM
> To: 'Irenee GROZ IG255340'; llvm...@lists.llvm.org
> Subject: Re: [llvm-dev] Risc-v Assembly printer function order
>
> On 8/7/2018 12:54 AM, 'Irenee GROZ IG255340' via llvm-dev wrote:
> > Hello,
> >
> > I am working on the assembly printer for RISC-V, more specifically on
> > the AsmPrinter class.
> > I altered the RISCV Backend to print C code instead of Assembly,
> > interpreted by libraries... (but that's not important)
> > My problem is that, for my application to work, I need to treat my
> > functions in the order they are in the original C file.
> > I discovered that these functions are not treated in this order.
> >
> > My question is : Is there a way to force llvm to treat the functions
> > in the order given in the original C file ? and how?
>
> The LLVM backend should generally print functions in the same order they
> appear in the IR.  This is an implementation detail, not a guarantee,
> but there currently aren't any backend passes that rearrange functions.

You could probably write a Module pass that sorted the Functions by source
location; that's the only solution that comes to mind. You'd need to
define the ordering across files (e.g., the source location of a function
defined in a header; this happens a lot in C++, not so much in C).
--paulr
Reply all
Reply to author
Forward
0 new messages