the declaration from Bug #38309 currently generates

Yes you are right, my idea was to avoid checking the non-cst index access for sub uses of the Value, in order to allow independent field GEP accesses to be candidate for SRA (for struct types(, but indeed just checking the first livel of ConstantExpr GEP might just be too complicated and I don't think that the inbound or inrange markers help here. (and multi-dimensional array GEP access would be inbound but wrong to SRA.

I see. yes the fix is still there and I checked that this bug doesn't regresses.

This fix the regression with multiple GEP arrays by allowing SRA for GEP ConstantExpr even if it might use an instruction containing indirect offsets access. The GlobalValue fields can be scalarized if they have StructType and not ArrayType with possible out-of-bound.

looking at it. reverting in the meantime is fine

• Fix comment

actually optnone is not well adapted here, since it demotes local optimizations on the functions, but we still want to keep scalar or target optimisations to be applied, but not interprocedural optimisations.

iterate with instructionsWithoutDebug
reduce testcase

Hi Martin,

I earlier suggested matching InstalledDir as a way to set an "anchor" or marker that tells apart the output before it from the one after it. This way none of the forbidden patterns would be matched before the line InstalledDir (in my case a . appears in an URL causing the test to fail).

on a second thought, "InstalledDir" only appears with -v, and is still too fragile (e.g if installed dir name also contains checked strings)

Hi Roger,

Re-commit patch at r341547 with modified test case to use an explicit root tree for libraries

https://bugs.llvm.org/show_bug.cgi?id=21360

In D45814#1081203, @compnerd wrote:

Do you have commit access or do you need someone to commit this on your behalf?

Hi Saleem,

Move the non-null name check out of GetProgramPath and add a test case.

The rebased llvm part, for ping.

damn it last diff was the llvm part (D31139). Here is the clang part.

hello, realizing that this has been stuck for a while now. did I answer all the concerns ? rebased patch,

Rebase. Update tests.

I realized that testing CCCisCXX for IsUnwindTablesDefault was not really good and useless here, because we cannot treat C as C++ mode. In fact only the file type matters, as seen in the tests.

Changes since last revision:

I didn't find an easy way factorize the change in IsUnwindTableDefault to support the multiple ARM toolchains. After a quick check in Triple::arm in Driver/Toochains, many seem impacted (excepted NetBSD and Darwin that uses DwarfCFI or SJLG). So here is an attempt to move this into a small arm hook and use.

oops yes of course. I forgot some bits while switching from testing the arch to testing the platform.

Update IsUnwindTablesDefault to test fno-exceptions. (see Darwin.cpp)

OK, we can refine so that unwind-table is also not generated for C++ -fno-exceptions.

Hello Eli,

forgot to give the motivating figure. this brings a code size reduction of 9.5 % (geomean of text sections sizes) on coremarkpro -Oz for cortex-m3 eabi

Yes, I also tried to look into this direction, but I did not find a clean way from the driver to emit the attribute based on codegen options and language. Also unwind-tables must not be the default for arm. (for C this is what I want to eliminate). In fact I haven't found an example of setting attributes in the driver. not sure it's even possible.

In D31139#863908, @efriedma wrote:

I'm sort of concerned this introduces a subtle hole in the semantics of IR auto-upgrade... but I guess it's unlikely to matter.

Some bits of the patch have weird indentation; please clang-format C++ code.

Rebase and do not emit unwinder directives if not needed. Update tests accordingly.

Rebase and cleanup NeedsUnwindTable for be variants.

• do not omit the frame pointer for netbsd-eabi and darwin-eabi

OK, I have created a RFE tracker (BZ #32501). I will forward to cfe-dev.

• Merge branch 'master' of ssh://codex.cro.st.com/llvm-arm/clang
• Don't need a frame pointer for EABIHF also (AAPCS)

• Check not mdisable-fp-elim for arm eabi when optimizing

• Fix thinko in test

Updating D31972: Do not force the frame pointer by default for ARM EABI

#

• NeedsUnwindTable check thumb arch

1. Updating D31139: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed with EHABI #

Fix thinkos/typos.

1. Updating D31140: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed in EHABI #

Set UWTable if the language requires an exception table.
Conservatively only for ARM (necessary to emit the .cantunwind directive). But could probably be enabled for all targets.

1. Updating D31139: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed with EHABI #

Emit cantunwind directive if uwtable is set and the function cannot throw
Emit unwind table if uwtable is set

Yes we can enable cantunwind with the nothrow gcc attribute when exceptions are enabled
Forcing it when exceptions are not enabled (e.g for attribute cleanup) would require -funwind-tables at function level anyway

In D31140#706411, @jroelofs wrote:

Can you clarify the logic here? It's my understanding that:

-fno-exceptions does *not* imply -fno-unwind-tables

however:

-fno-unwind-tables *does* imply that exceptions cannot be used on targets that require the tables to do unwinding.