Skip to content

Fix rdar://64538073 #3099

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 10,000 commits into from
Closed

Fix rdar://64538073 #3099

wants to merge 10,000 commits into from

Conversation

ahatanaka
Copy link

No description provided.

@ahatanaka
Copy link
Author

The new patch requires users to create a source file and pass the file name to the command line. I made this change since I wasn't able to find a clean way to teach the driver to process the arguments and create the correct CC1 invocations without passing a source file.

Copy link

@jansvoboda11 jansvoboda11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new patch requires users to create a source file and pass the file name to the command line. I made this change since I wasn't able to find a clean way to teach the driver to process the arguments and create the correct CC1 invocations without passing a source file.

This sounds like we're exposing an implementation detail to the clients and forcing them to work around it. Would it be possible to create the file internally in the dependency scanner? (Probably just in an in-memory VFS.)

The contents of the file don't play any role when scanning dependencies by module name, is that correct?

* but get the dependencies by module name alone.
*/
CINDEX_LINKAGE CXFileDependencies *
clang_experimental_DependencyScannerWorkerByModName_getFileDependencies_v0(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this now doesn't require a special worker, I think clang_experimental_DependencyScannerWorker_getModuleDependencies_v0 would be a clearer name. WDYT?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me whether the function name should end with getFileDependencies_v0 or getModuleDependencies_v0. The return type CXFileDependencies contains both FileDeps and ModuleDeps, so it seems to me that a name ending with getFileAndModuleDependencies_v0 would be more accurate, but the two functions declared above this one both use getFileDependencies.

clang_experimental_DependencyScannerWorkerByModName_getFileDependencies_v0(
CXDependencyScannerWorker Worker, int argc, const char *const *argv,
const char *WorkingDirectory, CXModuleDiscoveredCallback *MDC,
void *Context, CXString *error, const char *LookedUpModuleName);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just ModuleName might be clearer. Maybe this should be moved after the argv parameter, since those are the main inputs to the function.

@@ -45,6 +45,14 @@ class ReadPCHAndPreprocessAction : public FrontendAction {
bool usesPreprocessorOnly() const override { return false; }
};

class ReadPCHAndPreprocessByModNameAction : public ReadPCHAndPreprocessAction {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to inherit from ReadPCHAndPreprocessAction? I think PreprocessorFrontendAction should be just fine, since precompiled headers don't affect dependencies of a module.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be incorrect to inherit from PreprocessOnlyAction instead?

//
// RUN: echo %t.dir > %t.result
// RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format experimental-full \
// RUN: -generate-modules-path-args -module-files-dir %t.dir/custom \

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The -generate-modules-path-args and -module-files-dir options are orthogonal to whether we're scanning dependencies of a module by its name or a TU by its source file. You can simplify this test by removing the code testing these.

@hyp
Copy link

hyp commented Jul 24, 2021

You need to land it on next now instead of apple/main :)

git apple-llvm automerger and others added 24 commits July 26, 2021 03:47
This patch adds the -fminimize-whitespace with the following effects:

 * If combined with -E, remove as much non-line-breaking whitespace as
   possible.

 * If combined with -E -P, removes as much whitespace as possible,
   including line-breaks.

The motivation is to reduce the amount of insignificant changes in the
preprocessed output with source files where only whitespace has been
changed (add/remove comments, clang-format, etc.) which is in particular
useful with ccache.

A patch for ccache for using this flag has been proposed to ccache as well:
ccache/ccache#815, which will use
-fnormalize-whitespace when clang-13 has been detected, and additionally
uses -P in "unify_mode". ccache already had a unify_mode in an older
version which was removed because of problems that using the
preprocessor itself does not have (such that the custom tokenizer did
not recognize C++11 raw strings).

This patch slightly reorganizes which part is responsible for adding
newlines that are required for semantics. It is now either
startNewLineIfNeeded() or MoveToLine() but never both; this avoids the
ShouldUpdateCurrentLine workaround and avoids redundant lines being
inserted in some cases. It also fixes a mandatory newline not inserted
after a _Pragma("...") that is expanded into a #pragma.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104601
…f hasTrait<ReturnLike>.

This CL adds a new RegionBranchTerminatorOpInterface to query information about operands that can be
passed to successor regions. Similar to the BranchOpInterface, it allows to freely define the
involved operands. However, in contrast to the BranchOpInterface, it expects an additional region
number to distinguish between various use cases which might require different operands passed to
different regions.

Moreover, we added new utility functions (namely getMutableRegionBranchSuccessorOperands and
getRegionBranchSuccessorOperands) to query (mutable) operand ranges for operations equiped with the
ReturnLike trait and/or implementing the newly added interface.  This simplifies reasoning about
terminators in the scope of the nested regions.

We also adjusted the SCF.ConditionOp to benefit from the newly added capabilities.

Differential Revision: https://reviews.llvm.org/D105018
…orm.

This allows ORC to execute code containing Objective-C and Swift classes and
methods (provided that the language runtime is loaded into the executor).
Add 'enconding' attribute visitor.
Without it ASM printer doesn't use attribute aliases for 'enconding'.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D105554
Suppress only current warning on openmp-clang-x86_64-linux-debian

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D106777
Default to building the amdgpu plugin to use dlopen when hsa is
not found instead of disabling it.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D106600
…angler""

This reverts commit 2aa0cf1.
Get rid of reference to the temporary.
This patch extends support for (scalable-vector) splats in the
DAGCombiner via the `ISD::matchBinaryPredicate` function, which enable a
variety of simple combines of constants.

Users of this function may now have to distinguish between
`BUILD_VECTOR` and `SPLAT_VECTOR` vector operands. The way of dealing
with this in-tree follows the approach added for
`ISD::matchUnaryPredicate` implemented in D94501.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D106575
I have added a new FastMathFlags parameter to getArithmeticReductionCost
to indicate what type of reduction we are performing:

  1. Tree-wise. This is the typical fast-math reduction that involves
  continually splitting a vector up into halves and adding each
  half together until we get a scalar result. This is the default
  behaviour for integers, whereas for floating point we only do this
  if reassociation is allowed.
  2. Ordered. This now allows us to estimate the cost of performing
  a strict vector reduction by treating it as a series of scalar
  operations in lane order. This is the case when FP reassociation
  is not permitted. For scalable vectors this is more difficult
  because at compile time we do not know how many lanes there are,
  and so we use the worst case maximum vscale value.

I have also fixed getTypeBasedIntrinsicInstrCost to pass in the
FastMathFlags, which meant fixing up some X86 tests where we always
assumed the vector.reduce.fadd/mul intrinsics were 'fast'.

New tests have been added here:

  Analysis/CostModel/AArch64/reduce-fadd.ll
  Analysis/CostModel/AArch64/sve-intrinsics.ll
  Transforms/LoopVectorize/AArch64/strict-fadd-cost.ll
  Transforms/LoopVectorize/AArch64/sve-strict-fadd-cost.ll

Differential Revision: https://reviews.llvm.org/D105432
git apple-llvm automerger and others added 26 commits July 26, 2021 15:17
Thanks to gAlfonso-bit for the patch!

Differential Revision: https://reviews.llvm.org/D106691
- `scf.yield` in the "after" region supplies new arguments to the "before" region.

Differential Revision: https://reviews.llvm.org/D106806
These are required by MemIsShadow for checking if an address actually is shadow memory.

Differential Revision: https://reviews.llvm.org/D105745
Change SetCurrentThread*() logic not to include the zero padding
in PID/TID that was a side effect of 02ef0f5.  This should fix
problems caused by sending 64-bit integers to 32-bit servers.  Reported
by Ted Woodward.

Differential Revision: https://reviews.llvm.org/D106832
This is empty for now, but we will add a check that TBI is enabled once the
tagged pointer ABI for zircon is finalized. This depends on D105667.

Differential Revision: https://reviews.llvm.org/D105668
Ensure that libSupport does not carry any static global initializer.
libSupport can be embedded in use cases where we don't want to load all
cl::opt unless we want to parse the command line.
ManagedStatic can be used to enable lazy-initialization of globals.

The -Werror=global-constructors is only added on platform that have
support for the flag and for which std::mutex does not have a global
destructor. This is ensured by having CMake trying to compile a file
with a global mutex before adding the flag to libSupport.
Allegedly the DWARF backend ignores this field of DIEnumerator, but we
set it nonetheless in case we decide to use it in the future.
Alternatively, we could remove it, but it is simpler to pass down the
signed bit as it is in the AST for now.

Implemented to address comments on D106585
Before MASSV only supported P8 and P9 on AIX ans Linux . This patch proposes
MASSV to add support of P7 and P10 only on AIX too.

Differential: https://reviews.llvm.org/D106678
This will just be a call into __sanitizer_fill_shadow defined in the fuchsia source tree. This depends on D105663.

Differential Revision: https://reviews.llvm.org/D105664
…list of

module and file dependencies of a module for a particular compiler invocation

rdar://64538073
- Define a subclass of FrontendAction and call loadModule there.
- Remove the API for creating a worker just for
  clang_experimental_DependencyScannerWorkerByModName_getFileDependencies_v1.
- Add the capability to get the dependencies based on the module name to
  clang-scan-deps.
- Create a fake virtual source file instead of asking users to create
  one and pass it to the command line.
- Remove the "translation-units" output from test case
  modules-full-by-mod-name.cpp. The information isn't useful as the
  source file name isn't passed on the command line in this case.
- Inherit from `PreprocessOnlyAction`.
@ahatanaka
Copy link
Author

Hmm, I think rebasing onto next didn't go well. I'll open a new pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.