similar to: [LLVMdev] main, prologue & call

> I don't understand exactlly the difference among main function, prologue > code, and call function. I'm not sure that I understand your question. LLVM abstracts away target-specific information like function prologs and epilogs. If you are curious about the typical arrangement used by unix systems with _start and main, LLVM does not have that. Basically it uses 'main'

Chris Lattner wrote: >>I don't understand exactlly the difference among main function, prologue >>code, and call function. >> >> > >I'm not sure that I understand your question. LLVM abstracts away >target-specific information like function prologs and epilogs. > >If you are curious about the typical arrangement used by unix systems with

How/where are function prologs and epilogs generated, is it bespoke C++ code or TableGen generated ? If someone could point me in the right direction please. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090409/fb3336e4/attachment.html>

On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it bespoke C++ > code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue emission :)

Hello, Aaron > How/where are function prologs and epilogs generated, is it bespoke C++ code > or TableGen generated ? > > If someone could point me in the right direction please. Calling convention is really-really far from prologue/epilogue emission :) So: 1. Calling conventions Partly tablegen / partly C++ code. Look for CodeGen/SelectionDAG/CallingConvLower.cpp,

On Apr 9, 2009, at 11:11 AMPDT, Aaron Gray wrote: > On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info > > wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it > bespoke C++ code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Hi James, I also think that refactoring the code generation part is a great idea. That code is very complicated and difficult to maintain. I’ve wanted to rewrite that code for a long time, but just have never got to it. There are quite a few edge cases to handle (at least in the current code). I’ll take a deeper look at your patch. The abstractions that you mention, Stage and Block, are good

This is a great idea. But the order (psEncC->shapingLPCOrder) can be configured to 12, 14, 16, 20 and 24 according to complexity parameter. It's hard to get a universal function to handle all these orders efficiently. Any suggestions? Thanks, Linfeng On Mon, Feb 6, 2017 at 12:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > On 06/02/17 02:51 PM,

Hi Jean-Marc, Thanks for your suggestions. Will get back to you once we have some updates. Linfeng On Mon, Feb 6, 2017 at 5:47 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > On 06/02/17 07:18 PM, Linfeng Zhang wrote: > > This is a great idea. But the order (psEncC->shapingLPCOrder) can be > > configured to 12, 14, 16, 20 and 24 according to

Hi Jean-Marc, Thanks a lot for reviewing this huge assembly function! silk_warped_autocorrelation_FIX_c()'s kernel part is for( n = 0; n < length; n++ ) { tmp1_QS = silk_LSHIFT32( (opus_int32)input[ n ], QS ); /* Loop over allpass sections */ for( i = 0; i < order; i++ ) { /* Output of allpass section */ tmp2_QS = silk_SMLAWB(

Current set of patches for my work on segmented stacks. Go / dragonegg seems to work when using this code (I still haven't run any rigorous tests yet). Thanks! (Also on https://github.com/sanjoy/LLVM/tree/segmented-stacks) -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hello, I'd like to upstream our work over the time which the community would benefit from. This is a part of effort toward minimizing code size presented in here <https://llvm.org/devmtg/2020-02-23/slides/Kyungwoo-GlobalMachineOutlinerForThinLTO.pdf>. In particular, this RFC is about optimizing prolog and epilog for size. *Homogeneous Prolog and Epilog for Size Optimization, D76570

I attached a new patch with small cleanup (disassembly is identical as the last patch). We have done the same internal testing as usual. Also, attached 2 failed temporary versions which try to reduce code size (just for code review reference purpose). The new patch of silk_warped_autocorrelation_FIX_neon() has a code size of 3,228 bytes (with gcc). smaller_slower.c has a code size of 2,304

Hi Vedant, Thanks for your interest and comment. Size-optimization improves page-faults and a start-up time for a large application, which this enabling also followed. Even though I didn't see a large regression/complaint on a CPU-bound case, which is not a typical case for mobile workload, I wanted to be precautious of enabling it by default. However, as with default outlining case, I

Hi Sanjoy, The patch generally looks fine except for this part: diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp new file mode 100644 index 0000000..5ffb8f2 --- /dev/null +++ b/lib/CodeGen/StackSegmenter.cpp @@ -0,0 +1,48 @@ +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// The comment is obviously incorrect. diff --git

Hi! > diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp > new file mode 100644 > index 0000000..5ffb8f2 > --- /dev/null > +++ b/lib/CodeGen/StackSegmenter.cpp > @@ -0,0 +1,48 @@ > +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// > > The comment is obviously incorrect. Thanks. So much for lifting file

On Fri, 19 Dec 2003, Yueqiang wrote: > hi, > > like in C/C++ language there are time/date and istream::sync function. If an operation can be written in C/C++ or some other high-level language, then it should be. It can be directly compiled to LLVM bytecode. In our case you can llvm-dis llvm-gcc/lib/libstdc++.so to see what we compile it into. > also in RISC system Data/Inst Cache

Hi, Attached is a patch with arm neon optimizations for silk_warped_autocorrelation_FIX(). Please review. Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170131/9a912bb4/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hello > The prologue length in .debug_line is 157 for clang generated one, whereas > it is 34 for gcc generated one. I am curious about the results of making > prologue generated by clang look similar with one generated by gcc. > Could anyone let me know why this difference exists and if it is for good > /better purposes than for gcc. ? 1. This is not function prologue length.